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!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

aramboyajyan’s picture

aramboyajyan’s picture

Issue summary: View changes
aramboyajyan’s picture

Issue summary: View changes
mglaman’s picture

Assigned: aramboyajyan » Unassigned
Issue tags: +user experience

Adding 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 :(

aramboyajyan’s picture

You can easily test this even in local dev environment; here are the instructions:

  1. Install basic Commerce modules, including order and order UI
  2. Install Devel module.
  3. Install Maillog module. This will allow you to see the emails Drupal will try to send to users after completing the checkout.
  4. Configure Maillog: /admin/config/development/maillog
    • Make sure the Display the e-mails on page using devel module (if enabled). option is checked.
    • Optionally uncheck
      Allow the e-mails to be sent<code> if you're working in dev environment.</li>
      </ul></li>
      <li>If you are testing this from a non-adminstrative account (e.g. regular or anonymous users), be sure to grant the permission to see developer information. This is necessary so you can immediately see the output of <code>dpm()

      function.

      • Go to: /admin/people/permissions
      • Grant Access developer information to anonymous and authenticated users
    • Add a product, create a test order and check out the new links displayed on the page and in order email. Do this as both - logged in and anonymous user.

Hope this helps anyone who wants to test this patch - let me know if you have any other questions.

Thanks!

andyg5000’s picture

Looks good to me and passed my tests. Nice work :)

mcrittenden’s picture

Might 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?

aramboyajyan’s picture

Thanks 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 :)

aramboyajyan’s picture

Just 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 the destination 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!

Chris Matthews’s picture

Removed the trailing whitespace on line 64 of the patch in #9.