Opened 6 years ago

Closed 6 years ago

#1717 closed bug (fixed)

SSL login redirects to non-SSL

Reported by: planetcruiser Owned by: dima42
Priority: critical Milestone: 1.7
Component: BW General Keywords:
Cc:

Description

Issue:

Solution:

Hint:

Related tickets:

Change History (39)

comment:1 Changed 6 years ago by TimLoal

  • Component changed from unknown to BW General

comment:2 Changed 6 years ago by TimLoal

  • Milestone changed from Future to 1.0

Move to milestone 1.3 if not suitable on 1.0

LnP

comment:3 Changed 6 years ago by jsfan

  • Milestone changed from 1.0 to unassigned

comment:4 Changed 6 years ago by TimLoal

  • Milestone changed from unassigned to 1.0

comment:5 Changed 6 years ago by jsfan

  • Milestone changed from 1.0 to unassigned

comment:6 Changed 6 years ago by dima42

  • Owner set to dima42
  • Status changed from new to accepted

comment:7 Changed 6 years ago by dima42

  • Milestone changed from unassigned to 1.7

the culprit is routing/requestrouter.class.php:156.

note that it is not only the login redirection that is broken, but any url which comes as a result of e.g. submission of a form rather than a direct link.

i'll put in a fix for this in 1.7. it will solve this particular problem, but we actually have a lot of little places where the redirections are wrong. (for example, the "report bug" link at the bottom right of every page) grep -r "baseuri" . in the rox directory gives some really depressing results.

i may or may not attempt refactoring that depending on how much time i have.

comment:9 follow-up: Changed 6 years ago by crumbking

[env]
baseuri_http = "http://bw/"
baseuri_https = "https://bw/"
baseuri_override = "http://bw/"
; set override to https://bewelcome to force ssl, or http://bewelcome to disable it
force_ssl_sensitive = false
;if true, forces ssl for login, signup, verification, pwd change regardless of what other settings might suggest.

My above settings seems to work as I don't have a setup with SSL locally.

I'm no sure it's related but stylesheets are not loaded on adminwords etc. Still figure out why...

comment:10 Changed 6 years ago by crumbking

Oh and a general comment. SSL was never site-wide implemented as we still call google maps apis (v2) without SSL. Nasty warning messages showed up in some browsers. Also all external calls should be switched to SSL if we switch full to SSL.

comment:11 in reply to: ↑ 9 Changed 6 years ago by dima42

Replying to crumbking:

I'm no sure it's related but stylesheets are not loaded on adminwords etc. Still figure out why...

Thanks for catching that. Unfortunately adminwords isn't going through standard page routing so it was linking back to /htdocs/bw/... (there appears to be a "new" /admin/words page which does load fine, but doesn't have functionality unlike the "old" /bw/adminwords.php")

So I guess the best thing for those "deprecated" cases is to have baseuri predefined anyway. Fixed in https://gitorious.org/bewelcome/rox/commit/99c73ba63379c72e63e3dc3db6fd62561036bf61

comment:12 Changed 6 years ago by dima42

Oh, you also want a baseuri="http://bw/" line in rox_local.ini for the last commit to fix adminwords.

comment:13 Changed 6 years ago by crumbking

okay all "old" admin tools work now. though someone else have to test the ticket locally...

comment:14 Changed 6 years ago by shevek

  • Status changed from local_testing to needs_work

Deployed to alpha.

Surfing the site on https:// works fine except the search for members as Chrome blocks all access to unencrypted content. (In this case the call to the Google Maps API.)

Last edited 6 years ago by shevek (previous) (diff)

comment:15 Changed 6 years ago by dima42

Google Maps does have an SSL API which we could upgrade to. However, Open Street Map does not. (https://help.openstreetmap.org/questions/10920/how-to-embed-a-map-in-my-https-site) Also, Leaflet (which we use for access to either Google Maps or OSM) does not either. (http://leaflet.uservoice.com/forums/150880-ideas-and-suggestions-for-leaflet/suggestions/3194267-ssl-support-for-your-cdn-version-of-leafletjs)

Two possible solutions:

  1. We could set up a proxy to encrypt the data we get from OSM and Leaflet. It would be very resource intensive for OSM, and not resource intensive for Leaflet.
  2. We could disable SSL for pages with unencrypted external content. These (or their complement) would probably have to be hard-coded somewhere. We are of course already encrypting most sensitive content even when accessing through http; in addition to completing this, we could add the psychological help of forcing the "https" onto the user for those pages.

Anyone have suggestions or other ideas?

Some history: I actually just found a thread about this on the dev mailing list in 2008 with IE7 instead of Chrome as the culprit :). http://lists.bewelcome.org/pipermail/bw-dev-discussion/2008-September/002397.html

comment:16 Changed 6 years ago by crumbking

Get the warnings on alpha, too. I would prefer solution 2. Problem would still be the /signup/3 page with the maps. Might be good ask the questions on the list again. Maybe we have some experts there ;-)

comment:17 Changed 6 years ago by shevek

I also prefer option 2 as I don't think that signup/3 is a problem if we only disabled SSL for that page. As long as the password is sent via SSL that would be fine.

As we host leaflet locally it shouldn't be a problem to run that on SSL or am I missing something? Wouldn't solve the calls to openstreetmap of course.

comment:18 Changed 6 years ago by dima42

So actually this doesn't really work: if we are going to be moving from https to http, we are going to get a browser warning under some configurations anyway. (It will just be a leaving-ssl warning rather than a mixed-content warning.)

Our current target audience for site-wide SSL browsing are security-minded people who probably actually want the warnings. As far as I see the real problem is not the warnings, but the fact that the maps are just not serving on chrome as a result. I might have accidentally solved this; I only tested on Chromium (and Firefox) so please check behavior on other browsers. https://gitorious.org/bewelcome/rox/commit/9fd600dfb47f5fa42315d230b4514e120a26156d

Then for the "normal" users we can have an http site with sensitive forms by SSL, which as far as I know (?) doesn't have any scary warnings.

comment:19 follow-up: Changed 6 years ago by shevek

Just tested this. Seems to work. No idea why ;-)

A cleaner solution might be that we exchange http:// for remote links to https:// depending on the curren request. Is that possible with the setup we have at the moment?

comment:20 in reply to: ↑ 19 ; follow-up: Changed 6 years ago by dima42

Replying to shevek:

A cleaner solution might be that we exchange http:// for remote links to https:// depending on the curren request. Is that possible with the setup we have at the moment?

I don't follow. Isn't this exactly what //url does? Or do you mean somewhere else?

comment:21 in reply to: ↑ 20 ; follow-up: Changed 6 years ago by shevek

Replying to dima42:

Replying to shevek:

A cleaner solution might be that we exchange http:// for remote links to https:// depending on the curren request. Is that possible with the setup we have at the moment?

I don't follow. Isn't this exactly what //url does? Or do you mean somewhere else?

I was talking about the code in main.js. There is no //url as far as I can see but a hard ocded http:// for the Google Maps API.

comment:22 Changed 6 years ago by crumbking

I get mixed content warnings on IE8 on all pages with maps on alpha.

comment:23 Changed 6 years ago by shevek

Chrome just stores these in the console so they aren't visible. But that there would be some was to be expected wasn't it?

Trying to load the tiles via SSL gives a warning as well as they are served from cloudfront in the end which doesn't match with cloudmade.

comment:24 in reply to: ↑ 21 Changed 6 years ago by shevek

Replying to shevek:

Replying to dima42:

Replying to shevek:

A cleaner solution might be that we exchange http:// for remote links to https:// depending on the curren request. Is that possible with the setup we have at the moment?

I don't follow. Isn't this exactly what //url does? Or do you mean somewhere else?

I was talking about the code in main.js. There is no //url as far as I can see but a hard ocded http:// for the Google Maps API.

Stupid me not to recognize //url as a placeholder.

Fix clearly works for the problem described in the ticket.

By the way isn't #1716 fixed as well?

Last edited 6 years ago by shevek (previous) (diff)

comment:25 follow-up: Changed 6 years ago by shevek

Hm: Try to access this when not logged in: https://alpha.bewelcome.org/activities/14

For some reason the CSS files are loaded from http://alpha when the login wdget is shown.

comment:26 in reply to: ↑ 25 Changed 6 years ago by dima42

Replying to shevek:

Hm: Try to access this when not logged in: https://alpha.bewelcome.org/activities/14

For some reason the CSS files are loaded from http://alpha when the login wdget is shown.

How are you routing the activities code? We have this problem with adminwords too; it's because RoxFrontRouter is skipped in that code (not familiar with how, just know that it is; something to do with how htdocs is routed differently from build). The current behavior is that if RoxFrontRouter is never called, we default to http.

Replying to shevek:

By the way isn't #1716 fixed as well?

No, it wasn't. It's solved if the user accesses site via https, but the desired behavior is to send it to https even if user is on http. Users should not have the option of sending unencrypted passwords. Anyway, this is really easy to fix so I'll fix it.

Replying to crumbking

I get mixed content warnings on IE8 on all pages with maps on alpha.

Yeah, this is intended behavior (see comment 18). If someone has a better solution, please implement it; however, when I tried leaving ssl instead, I got equally nasty warnings (and then we in addition have to keep track of routing in e.g. cookies, which is ugly).

Please note that these warnings will not appear to most users trying to sign up: they will still be routed through the http pages, it's only that the forms' content will be submitted over ssl. This is not optimal, and should probably be changed in the future due to potential of man in the middle attacks. At that point, we may have to actually do something about the map in signup/3.

comment:27 Changed 6 years ago by shevek

I'm using routes.php and addRoute(). This should bring me into RequestRouter.

Regarding adminword: That's completely done using this rewrite rule 'RewriteRule ^/*([^/]*)\.php /bw/$1.php [L,R,QSA]'.

Which obviously only tackles the php files and not the CSS and JS loaded by them.

Last edited 6 years ago by shevek (previous) (diff)

comment:28 follow-up: Changed 6 years ago by dima42

I can't reproduce the problem with https://alpha.bewelcome.org/activities/14 anymore. I think I reproduced it once a few hours ago (weird layout, no colors) but now when I go there I see this image

Can you tell me your settings? (or if there's still something wrong with how that page looks)

comment:29 follow-up: Changed 6 years ago by crumbking

On alpha. I'm starting with non SSL. After login it redirects me to the SSL page of the site. I would expect to be still in non SSL after the login.

comment:30 in reply to: ↑ 29 Changed 6 years ago by dima42

Replying to crumbking:

On alpha. I'm starting with non SSL. After login it redirects me to the SSL page of the site. I would expect to be still in non SSL after the login.

I just tried and can't reproduce this. Details?

comment:31 Changed 6 years ago by crumbking

IE8/WIN7:

Es besteht ein Problem mit dem Sicherheitszertifikat der Website.

Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt.

Die Sicherheitszertifikatprobleme deuten eventuell auf den Versuch hin, Sie auszutricksen bzw. Daten die Sie an den Server gesendet haben abzufangen. Es wird empfohlen, dass Sie die Webseite schließen und nicht zu dieser Website wechseln.

Klicken Sie hier, um diese Webseite zu schließen.

Laden dieser Website fortsetzen (nicht empfohlen).

Weitere Informationen

The page suggests to close the webpage or (which I did) "load this website and go on (not recommended)".

After that you are still on https://alpha.bewelcome.org/ and see the internal (main) startpage

comment:32 Changed 6 years ago by dima42

Thanks. I downloaded IE and then could reproduce.

This is actually an IE bug: when we click to "load this website" it puts in a hard link to https which counteracts our internal redirection.

It's not going to be a problem for the main site since our certificate will be fine. Should we be trying to fix this for alpha? I assume this problem was there all along -- I didn't change anything about the login form redirection.

comment:33 Changed 6 years ago by crumbking

Well if this should be right on the live site than it's fine.

comment:34 in reply to: ↑ 28 Changed 6 years ago by dima42

Replying to dima42:

I can't reproduce the problem with https://alpha.bewelcome.org/activities/14 anymore. I think I reproduced it once a few hours ago (weird layout, no colors) but now when I go there I see this image

Can you tell me your settings? (or if there's still something wrong with how that page looks)

Bump. I think this is the only unresolved issue and I can't reproduce it.

comment:35 Changed 6 years ago by shevek

Sorry, can't reproduce anymore. Tried with empty cache and it worked just fine.

Might have something with what you answer to the security warning.

comment:36 Changed 6 years ago by shevek

  • Status changed from needs_work to to_alpha

comment:37 Changed 6 years ago by shevek

  • Status changed from to_alpha to testing

Deployed to alpha. Please test.

comment:38 Changed 6 years ago by sitatara

Tested on alpha with Firefox. Works fine for me.

comment:39 Changed 6 years ago by shevek

  • Resolution set to fixed
  • Status changed from testing to closed

No longer redirecting from SSL to plain. Closed as fixed.

Note: See TracTickets for help on using tickets.