|
|
Posted by Jerry Stuckle on 11/07/06 18:30
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.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|