Links with destination URLs are broken

I was having a similar issue. Namely that when you have uc_ssl configured such that Ubercart Non-SSL Switch: * is set to enabled, the customer pane is broken (there is an 'edit' link that takes you to /user/{uid}/edit?destination=/cart/checkout .

Id really rather not chew up the cpu with ssl on the whole site, but then again I guess firesheep makes it easy to steal login identities these days.. so maybe not such a bad idea.

either way though, I think uc_ssl isnt handling ?destination in its urls.

subscribe

This is really a problem.

Here is my situation: the edit links to individual users at example.com/admin/user/user don't work. They take you straight back to the destination which is the same page.

Here is the relevant code in my custom module:

<?php function mymodule_include_ssl_paths()
{
   $paths = array(
     'User Edit page' => 'user/*/edit*', //Secure User Edit page.
     'All Register pages' => '/register*', //Secure ALL register pages.
     'All Admin pages' => '/admin*', //Secure ALL admin pages.
   );

  return $paths;
} ?>

In reply to #1

This kinda sounds like maybe your SSL domain is not mydomain.com. Is your ssl domain www.mydomain.com? If so, then when you logged in, your session is ONLY good for www.mydomain.com and if you go to mydomain.com, you will NOT be logged in and thus you would receive this error. The best solution is to make absolutely certain that your site cannot be accessed via any domain other than your SSL domain (www.mydomain.com). The OTHER solution would be to make sure the SSO works between www.mydomain.com and mydomain.com which is probably the "correct" way to go about doing this. There are SSO modules available that will help you fix your issue. If you dont want to install another module, I can give u a quick 1 line hack for your index.php file or .htaccess file that will force all uses to use the correct domain.

#3 sounds like a different issue all together, I'll have to take a look and see if I cant reproduce that behavior and get it fixed. The path's should be redirected properly for something like that.

@crystaldawn,

uc_ssl fails when there is a destination added to the URL. Here is a simple example:

First, the relevant code in my custom module is:

<?php function mymodule_include_ssl_paths()
{
   $paths = array(
     'All Register pages' => '/register*', //Secure ALL register pages.
   );
  return $paths;
} ?>

Example of what is working:

http://example.com/user/register

gets redirected to

https://example.com/user/register

Example of what is broken:

http://example.com/user/register?destination=comment%2Freply%2F1161%23comment-form

is redirected back the page that had the link. And in this case an error gets shot out... "You are not authorized to view comments."

I promise to quickly test any patches to fix this problem.

Thanks for all your great work on this module.

Shai

subscribe

Hi you all,

I've had the same problem, I will explain my experience in case it could help someone else. I have a site with a long list of URL addressed through "https" protocol, most of them on the intranet part of the site. One day I realized that I could edit pages on a SSL environment from pages like:
https://www.example.com/es/node/6121/edit?destination=storm%2Fquotations

but not from:
http://www.example.com/es/node/8302/edit?destination=node%2Fedition%2Fno...

and both had to go to an address comanded by a rule on the uc_ssl.module as:
'Edit nodes 2' => 'node/*/edit*'

so pages with a format like:
https://www.example.com/es/node/3462/edit?destination=node%2Fedition%2Fn...

was working on he first case but not on the second. The reason was that despite on both cases I had to go to a page under the same rule 'node/*/edit*' that page itself is an SSL page, and on the first case I was pretending to go to it from another SSL page and on the second case from a non-SSL page.

I simply solved it adding the second page on a "SSL rule". It works for that but I still haven't found a way to solve another problem.

All the blocks I have on the site that are made with "views" display those useful floating links to go to the views edition page when you have proper permissions. Well, I have all the admin pages (incluiding obviously the views ones) under SSL. So, when I try to edit a block on the public-non-ssl part of the site clicking a link to the views edit page the links to the views have "http" and not "https", so it doesn't go to the views edition page. I haven't found still a way to solve it, and I still wonder if the module should know how to solve that situation.

Any idea?

Not sure if this addresses all of the problems described above, but one issue is that when a url contains a destination parameter, drupal_goto will use that rather than the path passed to it. So simply unsetting that fixes the problems I was having with the links in the customer pane (same as described in comment 1 above).

I've attached a patch so others can see if this fixes the problems they were seeing, too.

I am using current (6.x-1.26) version (above patch seems applied to this version) but there are still the same problems described above.

For example:

Secured with SSL all user pages - /user*, but not admin. When I go to admin/user/user to edit or delete any user from a list, which a path for example

/user/3/edit?destination=admin%2Fuser%2Fuser

It do nothing: stay or redirected to the same admin/user/user page

Another one:

if SSL secures pages /user* and you login with destination for example

<a href="/user/login?destination=cart%2Fcheckout">klick here to login</a>

Everything goes fine

BUT if you are in checkout, which is secured page and /user* pages are not, the above code will not work, as in previous example stay on the same page.

To make it work you need to include full path with http like:

<a href="http://www.domainname.com/user/login?destination=cart%2Fcheckout">klick here to login</a>

But if you would like one day to protect /user* pages, you will got vice versa problems..

Any Ideas how to solve these problems?

The patch in #9 works for me when going from an ssl page to another ssl page, have not tried ssl page to a non ssl page.

@westwesterson yes it works from SSL to SSL page, but as I mentioned it`s not work SSL page to non SSL, or vice versa.

#9 appears to work for me when moving between SSL & non-SSL pages.

#9 works here for me also, with Click here to login

Doing what #9 does on 7.x does not work.

Here's a patch for 7.x

This patch has been rolled into the 7.x release. If anyone wants to open one for D6 (I dont use d6 anymore myself), feel free and I'll roll that when I get a chance.