474641 - Watch-thread email notification links hard-code "http://", but should instead use HTTPS

Status: VERIFIED FIXED

(support.mozilla.org :: General, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

In our watch-thread email notifications, we have hardcoded the scheme as "http://":

"The page Keyboard shortcuts was commented by  at Wed 21 of Jan, 2009 10:45 PST
You can view the page by following this link:
http://support.mozilla.com/de/kb/tiki-index.php?page=Keyboard%20shortcuts#comments
Title: Tastaturkürzel
Comment: e5ne tastat4r 5st 2a-4tt
If you don't want to receive these notifications follow this link:
http://support.mozilla.com/de/kb/tiki-user_watches.php?hash=b0952c3ca1c0a09e7a9acf8a76d092b6"

Comment 1

[E. Cooper [:ecooper]]

The watches get the host portion of url from TikiLib::httpPrefix, which gets the http/https from $url_scheme defined in webroot/lib/setup/absolute_urls.php:49.

I wonder, are all watch URLs being set as http? Or just some of them?

Comment 2

[E. Cooper [:ecooper]]

"http" email links seem to occur only when anon users make comments or post in the forums.

There's an easy insertion point in fixing this, and it's just expanding TikiLib:httpPrefix to allow forcing "http" or "https". It's not very clean or sustainable route, though.

Nelson brought up the idea of just redirecting to https from http if the user is logged in, but since the tracking cookie is "secure" we won't know if the user is logged in or not already when he visits via http.

Any ideas?

Comment 3

[Chris Ilias [:cilias]]

(In reply to comment #2)
> "http" email links seem to occur only when anon users make comments or post in
> the forums.

I don't know if this matters, but it also occurs when a new page is created.

Comment 4

[E. Cooper [:ecooper]]

I wonder if it would be best to plop two lines of code in tiki-setup_base.php to redirect logged in users to https automatically.

Does anyone have a problem with that? It seems to be a much cleaner solution than making sure watch emails are all forced https.

Comment 5

[E. Cooper [:ecooper]]

I should mention that we can now checked for logged in users because  https://bugzilla.mozilla.org/show_bug.cgi?id=470517#c4 is no longer the case. That is, the cookie is valid between http and https.

Comment 6

[Reed Loden [:reed]]

(In reply to comment #5)
> I should mention that we can now checked for logged in users because 
> https://bugzilla.mozilla.org/show_bug.cgi?id=470517#c4 is no longer the case.
> That is, the cookie is valid between http and https.

Ugh, that's bad. I wonder who broke that.

Comment 7

[E. Cooper [:ecooper]]

Prod is now handing out secure cookies again. We're back to forcing https through all watch emails.

(In reply to comment #5)
> I should mention that we can now checked for logged in users because 
> https://bugzilla.mozilla.org/show_bug.cgi?id=470517#c4 is no longer the case.
> That is, the cookie is valid between http and https.

Comment 8

[Paul Craciunoiu [:paulc]]

So does that mean this is fixed?

Comment 9

[E. Cooper [:ecooper]]

Just to note for the upcoming freeze, I have a patch to post for this tonight. I'm just doing some extra testing on it to make sure it doesn't conflict with the fix for bug 444703.

Comment 10

[E. Cooper [:ecooper]]

This will land with bug 444703.

Comment 11

[Laura Thomson :laura]

Depends on bug now in 0.9, pushing to 0.9.

Comment 12

[E. Cooper [:ecooper]]

This landed with bug 444703 just a moment ago. It's in r22581/r22582.

All watch email links should now be forced to use https. If you come across one that isn't, please reopen and give the watch type.

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED per comment 13.

Comment 15

[Louis-Philippe Huberdeau]

Upstreamed under a preference.

https_external_links_for_users