   [web] secure login
  Right i have this website, which once the user goes to login, takes them to the secure version of the website (ie https), once logged in, it then takes them back to the non-secure site but should remember the user is logged in, how ever the session information is losti use session_start(); to remember the login details. So im thinking, maybe once the user logs in the whole website stays in the secured version OR once the user enters my website they are automatically sent to the secured site (this last method would be the easiest)is there any reason i shouldnt always make the user get redirected to the secure site (the only thing i can think of is that they get an UGLY url up the top in the url bar).or maybe i need a way to persist login info, which im not sure how to persist in a safe, secure way, as cookies can be intercepted etc...   
Quote:(the only thing i can think of is that they get an UGLY url up the top in the url bar).That's your problem then. I take it that you are using a "shared" SSL location like "https://ssl.myhost.com/~mydomainname.com".PHP sessions only work per domain since they work with cookies. Thus, the cookie is getting set on the SSL domain, but getting lost when you switch back. What you need to do is this:1) User logs in successfully on SSL domain.2) Generate random token.3) Enter token + user_id into a database table.4) Redirect the user back to the non-SSL site, passing the token as a paramater: mysite.com/?auth=big,long,random,token5) Check for the auth token: if isset($_GET['auth']) 6) Select the user_id from the database where the auth token matches.7) Delete the auth token from the database to prevent it from being re-used. As a precaution, you could also date stamp them and delete anyone that is older than a few minutes.8) Set a new $_SESSION variable. ie: do whatever you normally would do when the user logs in.Note that alternatively, you could pass the SID along the URL if the SSL box is physically the same, but it's not good practice to accept SIDs in the URL. They make it way too easy for people to hijack sessions. (Search engines tend to pick up on them, etc.) Another problem with that is that many people will have a different IP address when visiting a SSL site because of how their ISP is configured. (Some ISPs channel non-secure data through a proxy IP, but leave SSL data alone.) Thus, PHP may not even recognize the session as valid because a different IP started it. (Depends on your settings.)   ;  1. Secure login.2. ??????3. Profit.   ;  Please don't ever put session IDs in the URL - I use PHP's session.use_only_cookies to totally disable any possibility of having session ID in the URL (It's not secure; session IDs can leak and it's also vulnerable to session fixation attacks).To have cookies work between HTTP and HTTPS, you must ensure that you use the same host name for both.This is normally achieved by using a procedure I call "URL Canonicalisation":1. Register your domain name and any aliases (I'm assuming you've done this already)2. Decide which *HOST NAME* you want as your primary one for your web site. Pick EXACTLY ONE name which will be the official, correct name.3. Set up all of your aliases to do a redirect to the canonical host name (e.g. example.com REDIRECTS to www.example.com)4. Only run your web app on the canonical host name, not any other.When you buy your SSL certificate, you should do so for the canonical host name. Then there won't be any difficulty.It also helps search engines etc, as each page on your site has exactly one URL.If you're using an OS which has case insensitive filenames (or something else which is case-insensitive), then care should be taken to be totally consistent with links etc.Ideally, use a case sensitive filesystem (or have some server-side code which detects when the "wrong" case is used and does a redirect).Try to be consistent about other cases where you can have multiple URIs referencing the same page too (e.g. /members/ vs /members/index.php)Mark   