Cookie acceptance check on user login

Upgrading:

Offering a user to log-in in a situation where the login will automatically fail can safely be considered a bug.

Also, with all the ongoing login issues being reported (esp. with IE7 with strict security settings), it would be tremendously helpful to be able to rule out the 'cookie-not-accepted' problem. It would slash down on the number of reports about login issues: see the number of people reporting successful logins, which does not take (with the online user block displaying many times the username who keeps trying to log in).

Best practice noticed on other web sites:
- If the browser doesn't accept cookies, instead of presenting a login form, the user is directed to a help-page where it is described how to (selectively) allow cookies for each major browser.
- If a browser (Konqueror) asks the user whether to accept or not a cookie, a message is presented on the web page (that cannot be loaded because the server is waiting for the accept/refuse cookie reply) saying something like: "your browser is preventing a redirect - click on this link to access the page" (seen on yahoo).

this patch is a T if I ever saw one. But the issue is sound.

1) I don't know what is a 'T'.
2) the t() string must be escaped with double quotes because of the apostrophe in the string.
3) I am testing on Drupal 5 (don't have Drupal 6 set up because of mysql 4.0), but the the patch seems simple enough.

After having tested on D5, I get the drupal_set_message() text even though my browser DOES accept cookies. The login works, but the message is displayed nonetheless.

I am not going to work on this one. menu is enough.

Below is some instructions I found on another web site:

You are not logged into your account. This is likely due to cookies being disabled in your browser.

How to Enable Cookies

To enable cookies, follow the instructions below for the browser version you are using.

Windows IE 6.x Browser

1. Select Tools
2. Select Internet Options
3. Select the Privacy tab.
4. Select Advanced
5. Deselect override automatic cookie handling button
6. Click on the OK button at the bottom of the screen.
7. Click OK to exit
8. Select Tools
9. Select Internet Options
10. Select Delete Cookies
11. Select Tools
12. Select Internet Options
13. Select Delete Files
14. Close down all open Internet Explorer Browsers
15. Load it back up again and logon to StatCounter!

Windows IE 5.x Browser

1. Go to Tools on the menu bar
2. Pick Internet Options
3. Click the Security tab
4. Select the Custom Level tab
5. Under "Allow Cookies that are stored on your computer" click "Enable"
6. Under "Allow per-session cookies (not stored)" click "Enable"
7. Select OK, Yes you want to save the settings

AOL 8.0

1. From the AOL Toolbar, select Settings.
2. Select Preferences
3. Select Internet Properties (WWW)
4. Select the Privacy
5. Select Advanced
6. Deselect override automatic cookie handling button
7. Click OK to exit.

AOL 7.0 with IE 6.x

1. From the AOL Toolbar, select Settings.
2. Select Preferences
3. Select Internet Properties (WWW)
4. Select the Privacy
5. Select Advanced
6. Deselect override automatic cookie handling button
7. Click OK to exit.

AOL 7.0 with IE 5.5

1. From the AOL Toolbar, select Settings.
2. Select Preferences
3. Select Internet Properties (WWW)
4. Select the Security tab
5. Select the Custom Level tab
6. Under "Allow Cookies that are stored on your computer" click "Enable"
7. Under "Allow per-session cookies (not stored)" click "Enable"
8. Select OK, Yes you want to save the settings

Netscape 7.x

1. Click Edit on the Toolbar.
2. Click Preferences
3. Click the Privacy and Security category; expand the list to show the subcategories.
4. Click Cookies
5. Three options are displayed. Click the appropriate choice:
   • Disable cookies
   • Enable cookies for the originating web site only
   • Enable all cookies
   • If you want to be notified when a web site tries to set a cookie, select "Warn me before accepting a cookie."

Netscape 6.x

1. Click Edit on the Toolbar.
2. Click Preferences
3. Click the Privacy and Security category; expand the list to show the subcategories.
4. Click Cookies
5. Three options are displayed. Click the appropriate choice:
   • Disable cookies
   • Enable cookies for the originating web site only
   • Enable all cookies
   • If you want to be notified when a web site tries to set a cookie, select "Warn me before accepting a cookie."

Netscape 4.x

1. Go to Edit on the menu bar
2. Pick Preferences
3. Go to the Advanced option on the Category menu
4. Click the check box next to "Accept All Cookies"
5. Click OK

Netscape 3.x Clients

1. Go to Options on the menu bar
2. Pick Network Preferences
3. Click the Languages tab
4. Click the checkbox next to "Enable Java"
5. Click OK

Mac IE 5.x

1. Click Edit
2. Select Preferences
3. Under the Receiving Files option, select Cookies
4. Under "When receiving cookies:" select the desired level of cookie acceptance
5. Under "When receiving cookies:" select the desired level of cookie acceptance
6. Click OK to finish

Can this be considered to be copyrighted?

And just how this message will get to you when drupal_set_message uses SESSION? The issue is about losing your session id...

The last comment simply indicated that using drupal_set_message() is the wrong way to go.
It still remains a huge useability problem: many users contact us because they don't understand the cause of the problem.

On a related note, the message output by drupal_set_message() is very often missed by the users. We have more and more evidence of that, and it also causes problems. People are confused and don't know whether they have successfully posted a new post (invisible because on the moderation queue), whether their vote has been taken into account, whether they have successfully subscribed/unsubscribed from the newsletter, etc...
All of this is displayed by drupal_set_message() but the users don't see it.

In critical functions like in the current issue (login attempt), it would be better to redirect the user to a separate page with the message. This is how most other BB and CMS handle it: I am starting to see why it is the right choice to do so.

So, for the current issue, when processing a login form, Drupal should redirect to a special page with, for content, the error message and some of the information presented in #6.

On a more general note, if you theme your drupal_set_message wrong, tough luck. We could indeed do a redirect past auth and check whether we are indeed logged in and if not then display instructions. This would add a plus page load for every login. Opinions.

1) I'd love to see the "user doesn't accept cookies" issue fixed.

2) I believe the proposed change (extra page instead of drupal_set_message) is a too big change for now.

i don't think this issue is worth adding a new request for every login. we need a better solution, or no solution. my .02.

There is no bug here and it's not critical. We can also write code that issues a cookie for everybody --say, with a site name-- and the login submit function which is surely not the first page (at worst, second page load) a visitor gets, so the cookie should be there. This seems to be a widespread solution for teh problem. I will roll a patch during teh 'con.

Duplicates marked:
http://drupal.org/node/2946
http://drupal.org/node/99325

http://drupal.org/node/2946 should be active and this should be the dup. we always try to use the oldest issue. a pointer "there's some useful stuff in #xxxxxxx" in the original issue is a good way to direct people to something of value in a later duplicate. the only good reason to close an older issue is if the original got so confused and sidetracked by lame comments that no one can find the signal amidst all the noise and follow anything coherent. but there are hardly any comments in #2946 at all, and it's important for everyone to realize we've had this same issue for over 4 years now.

Fair enough I suppose, but is this a documented procedure?

I've always tried to determine the issue with the most relevant work put into it and dub THAT the master issue.

@bdragon: I guess it's not documented anywhere.
I have seen it happen bothways,