Problem/Motivation
Tokens for displaying order URL are taking the user directly to the order page, no matter if he is logged in or not.
This results in "403 Access denied" message shown for anonymous users, making it pretty confusing for end users and requiring more modules to override on the back end (e.g. Commerce Immediate Login module).
These tokens are used for sending success order emails and for showing the link to the order page after the checkout.
Proposed resolution
Instead of constructing the main link with direct order URL, use user/login
instead and pass in the real URL as a destination in query string.
This way users who are not logged in will be asked to login first, and users who are already logged in will just be redirected to the proper page.
Attached is the patch.
I tried to find similar issues or previous discussions on this topic and haven't found any.
Would like to hear your thoughts on this.
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#10 | order-url-tokens-2228011-10.patch | 3.94 KB | Chris Matthews |
| |||
#9 | order-url-tokens-2228011-9.patch | 3.95 KB | aramboyajyan |
#1 | order-url-tokens-2228011-1.patch | 1.82 KB | aramboyajyan |
Comments
Comment #1
aramboyajyan CreditAttribution: aramboyajyan commentedComment #2
aramboyajyan CreditAttribution: aramboyajyan commentedComment #3
aramboyajyan CreditAttribution: aramboyajyan commentedComment #4
mglamanAdding user experience tag. I think this is an EPIC improvement. I've had numerous complaints from clients based on this fact and them saying the system is broken.
Unfortunately I don't do client work anymore and cannot test in a viable environment :(
Comment #5
aramboyajyan CreditAttribution: aramboyajyan commentedYou can easily test this even in local dev environment; here are the instructions:
/admin/config/development/maillog
Display the e-mails on page using devel module (if enabled).
option is checked.function.
/admin/people/permissions
Access developer information
to anonymous and authenticated usersHope this helps anyone who wants to test this patch - let me know if you have any other questions.
Thanks!
Comment #6
andyg5000Looks good to me and passed my tests. Nice work :)
Comment #7
mcrittenden CreditAttribution: mcrittenden commentedMight be worth testing this along with https://www.drupal.org/project/login_destination or https://www.drupal.org/project/logintoboggan -- I believe both of those allow you to hard-set login destinations and ignore the ?destination= parameter altogether, which would either make the link NEVER work correctly, or maybe just make it work correctly only when you're already logged in.
Maybe special case it and use the old link format if either of those are installed?
Comment #8
aramboyajyan CreditAttribution: aramboyajyan commentedThanks for your messages guys.
I'll have a look at how does the patch behave with Login Destination and Login Toboggan.
In case there are some conflicts, I believe Mike's suggestion would be the most appropriate.
I'd just add maybe a notice for admins just so they know what's going on and that it's not a bug.
Will try this and keep this thread posted.
Sidenote - I noticed late that Drupal didn't like the formatting of my message; wrote it as markdown in Sublime text and then just copied as HTML :)
Comment #9
aramboyajyan CreditAttribution: aramboyajyan commentedJust tested this with "Login Toboggan" and "Login Destination" modules.
TL;DR - patch still works fine.
Added a message for admins about potential conflict with "Login Destination" module, because it depends on how they configure it.
Long version
LoginToboggan
Redirections seem to be related only to registrations.
I assume that users who are trying to see their own orders will not try to register again, because their account has already been created.
If they do, they will go through the workflow that is out of the scope of Commerce and they anyways won't be able to see the order then.
I have not found any issues between this patch and LoginToboggan module.
Login Destination
There is an issue if the module is configured to redirect URLs that include "user/login" OR when the module ignores
destination
parameter in the query string.I believe this is part of a bigger issue, which is inability of
drupal_match_path()
to match paths that include query string. In this case, the perfect solution would be to exclude*?destination=user/*/orders/*
from Login Destination rules in order for this to work properly.I added a notification message for administrators. It will appear on Commerce Order settings page only if the
login_destination
module is installed and if thedestination
parameter is ignored.Also, a new checkbox has been added that will allow users to ignore the warning - in case they want to override this through a custom module or add
user/login
path to the list of excluded redirections.Attached is the patch - thanks!
Comment #10
Chris Matthews CreditAttribution: Chris Matthews as a volunteer commentedRemoved the trailing whitespace on line 64 of the patch in #9.