I was testing various security approaches for a project I am currently working on and decided to test out the HTTP authentication setting.

I turned it on, tried it out, decided it was inappropriate for the task, and turned it off.

Now, for some reason, Safari for PC can no longer log into the website.  IE7, Opera, and Firefox all work fine (though I had to close those browsers and restart to drop the HTTP setting).

I have confirmed that the HTTP auth. setting has been turned off for all templates, and everything is working normally in all other browsers.

Also, Safari was able to login perfectly prior to the HTTP auth. toggle.  I have updated the Safari browser and cleared the cache.

Any ideas why this is the case?  Is it EE or Safari?

I am on PC:
EE v1.6.3, Build 20080421
Safari 3.1.2 does not log in
Firefox 2.0.0.14 logs in successfully
IE7 logs in successfully
Opera 9.27 logs in successfully

May I ask what you mean by ‘not being able to login’. Do you receive an error message, blank screen, hanging, etc?

Sure Justin - by “not able to login” I mean that, in Safari, when I type a username and password into the login form fields, I am taken to the “Thank you, you are now logged in” screen, then when the redirect kicks in (as is normal), I am taken back to the correct redirect url.  However, I am not logged in.  And in this case, since the correct redirect url goes to a members only template, I am instead shown the homepage template (though the url is still the correct logged in redirect address) as is the correct behavior as set in the admin for a non-logged in user.

Is that clear?

So the login process gets started, says I am logged in, but then apparently the login doesn’t stick, because in the next instant I am not logged in and am instead restricted out of the redirect template.

Safari has given me something similar in the past, try going to preferences -> security -> show cookies. Look for your domain in the list, and remove all cookies that pertain to your domain. This should resolve the issue.

Thanks for the suggestion Justin, but I have done that without results.  All cookies have been removed.  However, in doing this, I discovered the problem - it wasn’t old cookies but the fact that Safari wouldn’t accept new cookies from the site.  the setting “accept cookies only from sites you navigate to” is now blocking cookies from my site, even when I ‘navigate’ to it, and even though it was working well pre-HTTP authentication experiment.  By changing the setting to “accept cookies always”, the site behaves normally and cookies are accepted and stored.  However, this is not the preferred setting and I wonder why Safari’s mind changed regarding the site - it seems there is still something fishy going on - but, it works well enough to get the job done, though less than ideally.

Thanks for your attention Justin.

I’m glad you were able to resolve the issue. I’m not sure what would cause Safari to act in such a way. Closing out the thread, thanks for the report.

What are you using for a cookie domain, Lee?

Derek, I would love to have an informed answer, but I actually don’t have anything for a cookie domain - I know where that setting is in the CP, but I have till now assumed that the setting could (should?) be left blank in most cases and the default EE cookies would work properly (as they always have in the past).

If I should be adding something to this field when I set up a site, please advise.  As a note, I am running the entire site in HTTPS with a few .htaccess rewrites to keep every visit to the site secure.  Could this play a role in Safari’s behavior?

Thanks for your attention Justin and Derek.

No, if it is blank, then every subdomain (www vs no www for example) would have different cookies; see the docs on cookie settings for more details.  Certainly .htaccess + SSL could be at play, but both would simple to remove from the equation to make sure things are working properly.  SSL requires a subdomain, incidentally, so that could be why one or more browsers would not accept your cookies.  As an example, you could not run an HTTPS site from example.com but would need to do so from secure.example.com.

Derek, I have added my domain to the cookie domain field.  That did not change Safari’s behavior.

Incidentally, I don’t think you are exactly right about the SSL situation - my understanding is that SSL doesn’t require a subdomain, rather it must be associated with one or the other, either .domain.com or domain.com, but depending on which you choose, the other won’t work (with the SSL).  In the site I am building now, I have SSL to work without a subdomain ... so it is working at domain.com.  I can pm you the site if you are interested.

I will check out Safari behavior when moving SSL and .htaccess out of the flow and report back.

Thanks.

If I recall, there are some wild card certificates that will work without a subdomain, but I do have memory of there being problems either with certain servers or with certain browsers with certificates issued without a subdomain.  It’s been years, though, so I’ll do some digging for the specific issue I am remembering.

When you are testing sans .htaccess and SSL, please also make sure that you have no Input Managers installed in Safari that might be interfering.

What I was thinking of is unrelated, Lee, so if your SSL certificate is issued for the domain you are using, or is a wildcard certificate, that part should be fine.  Are you using a separate path.php and index.php in the secure html directory?  Also, if your tests are unfruitful, you can email Justin via his profile page providing him with the location and authentication information so you can have another datapoint to determine if it’s a server/browser issue or just one local to your browser/machine/network.

Awesome - thanks Derek.  As I understand your question, yes, I have separate path.php and index.php files in my server root directory - as is part of the standard EE installation.

I am deep into the next quicksand pool already, but I will get back to this issue soon and post to this thread what I discover.

Thanks again.

Any news, Lee?

Derek, I did test with https and .htaccess removed.  Still does not work.  I will pm Justin with the site info to confirm or disconfirm the problem as local.

Just a quick note, please email me (not PM) the information. Include a link to this thread too, if you will. Thanks!

Greetings again. Was the problem corrected, or would you still like me to take a look?

Justin, I just sent you an email with the site and login info.  Thanks.

After some investigation by Justin, this problem has been tracked down and solved.  Apparently Safari takes “case” into consideration, at least in some contexts.  I was using caps in portions of the URLs as configured in the CP > Admin > System Preferences > General Configuration settings.  Changing these URLs to use all lowercase solved Safari’s cookie problem when the browser’s cookie preferences were set to “accept cookies only from sites you navigate to”.

Big thanks to Justin for tracking this down and suggesting the solution.