Problem Getting Script's URL ($_SERVER['PHP_SELF'] not what I expected)

[Tom]

I have a function that restricts access to a page to logged in users.
When a user who isn't logged in goes to the page, it will dynamically
generate a login form.

I'm trying to use it in conjunction with the free shared SSL
certificate offered by my host. To use SSL, you would change a URL
like this

http://mydomain.com/page.php

to

https://ssl.myhost.com/mydomain.com/page.php

My problem: when my script dynamically generates the login form, it
uses the $_SERVER['PHP_SELF'] value in the action field. But this ends
up being '/page.php' rather than '/mydomain.com/page.php' so my form
gets submitted to

https://ssl.myhost.com/page.php

instead of

https://ssl.myhost.com/mydomain.com/page.php

Simple I thought, I'll just use the SERVER or ENV variable that gives
me the full url. My problem: it doesn't seem to exist!

Anyone have any suggestions? Anyone else confront and solve this
issue?

Thanks,
Tom

[Erwin Moller]

Tom wrote:

I have a function that restricts access to a page to logged in users.
When a user who isn't logged in goes to the page, it will dynamically
generate a login form.

I'm trying to use it in conjunction with the free shared SSL
certificate offered by my host. To use SSL, you would change a URL
like this

http://mydomain.com/page.php

to

https://ssl.myhost.com/mydomain.com/page.php

My problem: when my script dynamically generates the login form, it
uses the $_SERVER['PHP_SELF'] value in the action field. But this ends
up being '/page.php' rather than '/mydomain.com/page.php' so my form
gets submitted to

https://ssl.myhost.com/page.php

instead of

https://ssl.myhost.com/mydomain.com/page.php

Simple I thought, I'll just use the SERVER or ENV variable that gives
me the full url. My problem: it doesn't seem to exist!

Anyone have any suggestions? Anyone else confront and solve this
issue?

Thanks,
Tom

Hi Tom,

Why not hardcode the url instead of using PHP_SELF?

Also, pay attention to possible sessionloss.
The cookie that contains the PHPSESSID will only be send to the domain that
set it. (Possibly it will also not be send by change of protocol
http->https, I am not sure about that)

So if you create a session in www.myhost.com, it is NOT accessable by
ssl.myhost.com.

Regards,
Erwin Moller

[John Dunlop]

Erwin Moller:

Why not hardcode the url instead of using PHP_SELF?

Well said that man! I second that.

--
Jock

[Tom]

Thanks for the suggestion. As a matter of fact, after some quiet
reflection away from the computer, that's what I ended up doing and
just added an argument to the function I use that allows the value to
be hardcoded, something like this:

php_guard_page($min_access_level=1, $action_field='dynamic')

The session-loss, as you anticipated, is the bigger issue I now
confront. This is part of a framework I use for multiple projects
which is the reason why I hesitated at something like hard-coding a
url. In any event, the idea is: a visitor can browse around open
non-restricted parts of the site then when they want to look at a
restricted page -- bam! hit them with the login form. In this
particular instance, I wanted to run the login through my host's shared
SSL -- which is on a different domain.

Two questions:

1. Is this necessary? Is using an unencrypted login form a significant
risk? What are the risks.

2. Is this possible? I quickly came to realize that I wasn't
understanding how the shared SSL certificate function. I was thinking
of it simply as kind of an extra layer of security being put on top of
my scripts. Any recommendation on how to best implement secure logins
with PHP using a shared certificate in this manner?

Links to good articles on the subject are welcome.

Thanks,
Tom
Erwin Moller wrote:

Tom wrote:

I have a function that restricts access to a page to logged in users.
When a user who isn't logged in goes to the page, it will dynamically
generate a login form.

I'm trying to use it in conjunction with the free shared SSL
certificate offered by my host. To use SSL, you would change a URL
like this

http://mydomain.com/page.php

to

https://ssl.myhost.com/mydomain.com/page.php

My problem: when my script dynamically generates the login form, it
uses the $_SERVER['PHP_SELF'] value in the action field. But this ends
up being '/page.php' rather than '/mydomain.com/page.php' so my form
gets submitted to

https://ssl.myhost.com/page.php

instead of

https://ssl.myhost.com/mydomain.com/page.php

Simple I thought, I'll just use the SERVER or ENV variable that gives
me the full url. My problem: it doesn't seem to exist!

Anyone have any suggestions? Anyone else confront and solve this
issue?

Thanks,
Tom

Hi Tom,

Why not hardcode the url instead of using PHP_SELF?

Also, pay attention to possible sessionloss.
The cookie that contains the PHPSESSID will only be send to the domain that
set it. (Possibly it will also not be send by change of protocol
http->https, I am not sure about that)

So if you create a session in www.myhost.com, it is NOT accessable by
ssl.myhost.com.

Regards,
Erwin Moller

[Erwin Moller]

Tom wrote:

Thanks for the suggestion. As a matter of fact, after some quiet
reflection away from the computer, that's what I ended up doing and
just added an argument to the function I use that allows the value to
be hardcoded, something like this:

php_guard_page($min_access_level=1, $action_field='dynamic')

The session-loss, as you anticipated, is the bigger issue I now
confront. This is part of a framework I use for multiple projects
which is the reason why I hesitated at something like hard-coding a
url. In any event, the idea is: a visitor can browse around open
non-restricted parts of the site then when they want to look at a
restricted page -- bam! hit them with the login form. In this
particular instance, I wanted to run the login through my host's shared
SSL -- which is on a different domain.

Two questions:

Hi

1. Is this necessary? Is using an unencrypted login form a significant
risk? What are the risks.

The biggest risk of using unencrypted login is simple: eavesdropping.
If somebody taps into the networktraffic (something that can happen anywhere
between the two IP-adresses), he can see the username password in the
IP-packages. Simple as that, just in plaintext.

How big this risk is, is completely beyound my knowledge.

>
2. Is this possible? I quickly came to realize that I wasn't
understanding how the shared SSL certificate function. I was thinking
of it simply as kind of an extra layer of security being put on top of
my scripts. Any recommendation on how to best implement secure logins
with PHP using a shared certificate in this manner?

No, sorry, not my area of expertice. :-/

>
Links to good articles on the subject are welcome.

Tom, I think you might get luckier with help on using and implementing HTTPS
in an Apache newsgroup.
I am sure a few in here know how to do it, but it is a little off topic in
this ng. SO if you need help quickly, go there.

If you hit a roof with sessionloss between your servers, come back here.
With that we can possibly help. :-)

Regards,
Erwin Moller

>
Thanks,
Tom

[Jerry Stuckle]

Tom wrote:

Erwin Moller wrote:

>>Tom wrote:

>>>I have a function that restricts access to a page to logged in users.
When a user who isn't logged in goes to the page, it will dynamically
generate a login form.

I'm trying to use it in conjunction with the free shared SSL
certificate offered by my host. To use SSL, you would change a URL
like this

http://mydomain.com/page.php

to

https://ssl.myhost.com/mydomain.com/page.php

My problem: when my script dynamically generates the login form, it
uses the $_SERVER['PHP_SELF'] value in the action field. But this ends
up being '/page.php' rather than '/mydomain.com/page.php' so my form
gets submitted to

https://ssl.myhost.com/page.php

instead of

https://ssl.myhost.com/mydomain.com/page.php

Simple I thought, I'll just use the SERVER or ENV variable that gives
me the full url. My problem: it doesn't seem to exist!

Anyone have any suggestions? Anyone else confront and solve this
issue?

Thanks,
Tom

Hi Tom,

Why not hardcode the url instead of using PHP_SELF?

Also, pay attention to possible sessionloss.
The cookie that contains the PHPSESSID will only be send to the domain that
set it. (Possibly it will also not be send by change of protocol
http->https, I am not sure about that)

So if you create a session in www.myhost.com, it is NOT accessable by
ssl.myhost.com.

Regards,
Erwin Moller

Thanks for the suggestion. As a matter of fact, after some quiet
reflection away from the computer, that's what I ended up doing and
just added an argument to the function I use that allows the value to
be hardcoded, something like this:

php_guard_page($min_access_level=1, $action_field='dynamic')

The session-loss, as you anticipated, is the bigger issue I now
confront. This is part of a framework I use for multiple projects
which is the reason why I hesitated at something like hard-coding a
url. In any event, the idea is: a visitor can browse around open
non-restricted parts of the site then when they want to look at a
restricted page -- bam! hit them with the login form. In this
particular instance, I wanted to run the login through my host's shared
SSL -- which is on a different domain.

Two questions:

1. Is this necessary? Is using an unencrypted login form a significant
risk? What are the risks.

2. Is this possible? I quickly came to realize that I wasn't
understanding how the shared SSL certificate function. I was thinking
of it simply as kind of an extra layer of security being put on top of
my scripts. Any recommendation on how to best implement secure logins
with PHP using a shared certificate in this manner?

Links to good articles on the subject are welcome.

Thanks,
Tom

(Top posting fixed)

Tom,

It's not *necessary* to use an SSL certificate, but if the login gives
access to sensitive data (i.e. credit card numbers, software available
for download by subscription, etc.), it's a good idea.

There is a slight chance that someone can intercept the unencrypted
login and get into your site. This is most likely to happen at the
first or last step in the path from the client to your site, but can
happen anywhere along the path. Is it a big problem? Probably not.
But it's good to be safe.

From the PHP end you don't have to do anything. The browser and Apache
take care of everything for you. The browser gets the info from the
user and encrypts it. This is sent down the link and received by
Apache, which then decrypts it. When it gets to your page, the data is
ready for use. In fact, it looks exactly the same whether it was sent
over an encrypted link or a non-encrypted link.

So all you need to do is have the users use

https://www.example.com/login.php

instead of http://... and it will be encrypted.

This should work on a shared certificate, also, although some browsers
may give a warning about the certificate belonging to another domain.

P.S. Please don't top post. Thanks.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================