CUNY Academic Commons

Have you had any more thoughts about this, Chris?

I'm not entirely sure how the entire cookie loading process works, but it seems like we should be able to do the following things in quick succession before a page loads: attempt to set a cookie, check to see if it's set, and display a warning if not. You want to whip something up (maybe hooked to plugins_loaded) that is a proof of concept?

I'm thinking we'd only want to load it on the login page, since we don't want to display the message to people who are just browsing the site.

Boone, Chris,

I added some javascript to cac-custom-js.js to test for cookie support and display an error message on the login page if they aren't enabled. It currently only works if a user visits the login page. The code needs to be updated to work with the dropdown login form in the toolbar (buddybar?).

Boone,

Where does that login form come from? I've been looking through the theme and the functions.php / bp-custom.php files and I can't seem to find it. If you could point me in the direction of that form I should be able to get this closed out rather quickly.

The code is in a new topic branch titled cookie-test

Commit: https://github.com/castiron/cac/commit/1c0aff0fd10cdde8217ab3af68e8c2554210d514

This looks good, Dom.

How can I capture that failure and properly redirect? Is there a hidden "login failed" input that I can add to handle this situation?

I can't see an obvious place to do this, if you're hooking to 'login_head'. The alternative is to find a filter that appears only when the creds were accepted, and to hook something to that filter to check whether the login was successful. Like https://github.com/castiron/cac/commit/d250f67076c80423e32311478614f60bcdec540e This seems like it works. Give it a test run, and maybe write some better inline docs than I've written (none :) )

Also, I forgot to mention that bp-nelo/functions.php is not loaded on subdomain sites. You may consider adding this to an existing mu-plugins file, such as the generic cac-functions.php that exists on the master branch.

Awesome, gonna play around with that new filter and move that code to cac-functions later today. Will let you know when I've pushed it up.

Thanks for the work on this. The error message about the cookies is fine, especially with the link to help them with enabling cookies. You may consider changing the link to, http://support.google.com/accounts/bin/answer.py?hl=en&answer=61416, as the one given doesn't directly explain how to enable cookies and might appear at first glance to be more about Google accounts.

Boone,

Gonna try and have some new commits on this issue later today. It's so close to done I just wanna get it closed out.

Chris,

I would change the link if I could, but it's in WordPress core, so I think we should leave it the way it is for now.

Boone,

I've taken my function and your function and moved them both to mu-plugins/cac-functions.php. I also added some comments as you requested, and shortened up your function a little. Together they both seem to resolve this issue. I've tested with cookies off on both the cac home page and some subdomains. I've also tested by going directly to the login page and from the login dropdown in the buddybar. Everything looks good. I also tested with cookies on to make sure there were no unexpected side effects from the code during "normal" login operations.

Chris,

I wasn't totally accurate in my last response. What this code does is check to see if WordPress has already set its internal no cookies error, and if not, it sets it manually. The issue is that WordPress does not check for that error until someone tries to login. So I can use the URL you provided but it will not be the link in that error message in all cases. Basically the only time the manual error is displayed is when a user goes directly to the login page. In all other circumstances WordPress' core error will be rendered. If we use your link then we'll have functionality that displays the same error message but with a different link depending on how the user got to the login page.

Would you (or Boone) please let me know if you'd like me to update the link to your version? Once that's ironed out I think we can close this issue.

Commit: https://github.com/castiron/cac/commit/5eaad5849ab2b8ea61c772356532feb810b7f214

I like the expanded comments. There's something I don't understand about this new logic though.

cac_no_cookie_login_redirect() now FIRST sets $r to wp_login_url() and THEN checks if the user is not logged in and (again) sets $r to wp_login_url() and finally returns $r. Won't this function now always return $r with the value of wp_login_url()? Is that what we want it to do here? If the function sets $r to wp_login_url() as its first action, why even bother checking if the user is logged in?

I have a feeling that you meant to remove that first assignment, but I don't want to change it if there's some reason for it to be there.

I think this can be closed as soon as we figure out if that first assignment is really supposed to be there or not.

I've added myself as a watcher. Is there something I can do here so you can focus on the 1.4 deadline?

Thanks, Dom. Please feel free to have a look. My hack the first time around was to change login_redirect based on whether the current user is logged in. But this is too generous a condition - it catches normal logins too, so that you always have to log in twice. I'm guessing something can be done by looking at the referer URI or something like that, but I'm not sure. If you have time to look, please do, but it's my mess, so don't feel obligated to clean it up :)

It's a small mess and I'm already familiar with this issue. You focus on the 1.4 deadline and I'll look into this.

Your hunch seems to be correct, by checking TEST_COOKIE the redirect appears to work the way we want it to. I tested with cookies on and off and logged in from both the login page and the buddybar. Let me know if it works on your end.

Commit: https://github.com/castiron/cac/commit/b1cde8d3d8cff3d8fe07f659a89761b74c32816b

There's gotta be a simpler way to address this issue. I've marked #2193 as a duplicate incase we need to reference any discussion from that thread.

I'll see what else I can come up with to resolve this issue as I close out more 1.4.9/1.4.10 issues.

Just wanted to post a quick update here before I forgot.

I'm in the new Fitterman building right now between classes. I'm on the BMCC-FH wireless.

I just experienced the weird "double login" error we've been hearing about from some of our users. My first attempt to login redirected me to wp-login and warned me that I must enable cookies to login to the site. My second attempt let me in with no errors.

I'll do some more testing before my next class to see if I can uncover any potential avenues that could help to address these annoying login issues.

Boone, that sounds fine however, I turned off cookies in Chrome and tried to log in and it just did nothing. There was no WP error message.

I don't think this is worth spending time on right now (there are probably very few users who turn cookies off and those who do probably know enough to turn them back on), but maybe we can keep it in the back of our minds and if we see someone has done something along these lines in the future we can look at creating a new ticket and revisiting.