On 26 March 2013 18:37, Steven Walling swalling@wikimedia.org wrote:
On Tue, Mar 26, 2013 at 11:34 AM, Oliver Keyes okeyes@wikimedia.org wrote: I got one too. My question (asked on IRC, but throwing out here for wider discussion): what's the rationale with directing people to the non-secure site? Did Ops object to https?
For reference: our current emails direct to vanilla HTTP, e.g. non-Echo stuff. It might be a more general request to make of Ops.
On Tue, Mar 26, 2013 at 9:00 PM, Fabrice Florin fflorin@wikimedia.org wrote:
On Mar 26, 2013, at 5:43 PM, Oliver Keyes wrote:
On 27 March 2013 00:37, Fabrice Florin fflorin@wikimedia.org wrote: Thanks, Oliver.
I would give the 'HTTPS' feature a lower priority than getting Echo deployed on time. This is something we can revisit after we are deployed, I don't view it as a blocker for now.
Sure, I don't think it's a blocker at all. But it's not a particularly big change, either ;p.
Cool. I just want us focused on the most important features first, so we can ship on time ;o)
On Mar 26, 2013, at 7:49 PM, Luke Welling WMF lwelling@wikimedia.org wrote:
The easy way of changing to https looks to be adding a single character to the definition of $wgServer in LocalSettings.php.
$wgServer is used everywhere, I believe even for reader access, so I vote strongly against this change. ;-)
Normally the correct way of handling this is WebRequest::detectServer() which uses the protocol of the user's browsing state (if https, then https). I take this is a problem because the messages are decoupled between the event trigger and the recipient?
BTW, this sort of mediawiki discussion should probably be on a lis where much more experienced mediawiki devs can answer, so I'm moving it there.
That would change it in a few other places though, so sounds like 1 second of editing and 1 day of testing.
We could hack it in just for Echo, but that would either be hacky and specific to targeted installations or break on installs that don't have identical http and https urls.
BTW, my opinion is I'm okay with using http://... ($wgServer) right now for release and just capturing this request as a bug in bugzilla or in Trello for now.
Thanks, Terry!
We'll let you make the final call on this request.
From a product standpoint, it's nice to have, but not critical for our upcoming deployment of Echo.
I am encouraging the team to reduce the number of deliverables for this deployment, so we can deploy as close to schedule as possible. :o)
So anything that is not absolutely critical for our minimum viable product should be off the table for now -- and can be revisited later. This seems like a good example of a request that can wait.
Thanks for your understanding!
Fabrice
On Mar 28, 2013, at 11:56 AM, Terry Chay wrote:
On 26 March 2013 18:37, Steven Walling swalling@wikimedia.org wrote:
On Tue, Mar 26, 2013 at 11:34 AM, Oliver Keyes okeyes@wikimedia.org wrote: I got one too. My question (asked on IRC, but throwing out here for wider discussion): what's the rationale with directing people to the non-secure site? Did Ops object to https?
For reference: our current emails direct to vanilla HTTP, e.g. non-Echo stuff. It might be a more general request to make of Ops.
On Tue, Mar 26, 2013 at 9:00 PM, Fabrice Florin fflorin@wikimedia.org wrote:
On Mar 26, 2013, at 5:43 PM, Oliver Keyes wrote:
On 27 March 2013 00:37, Fabrice Florin fflorin@wikimedia.org wrote: Thanks, Oliver.
I would give the 'HTTPS' feature a lower priority than getting Echo deployed on time. This is something we can revisit after we are deployed, I don't view it as a blocker for now.
Sure, I don't think it's a blocker at all. But it's not a particularly big change, either ;p.
Cool. I just want us focused on the most important features first, so we can ship on time ;o)
On Mar 26, 2013, at 7:49 PM, Luke Welling WMF lwelling@wikimedia.org wrote:
The easy way of changing to https looks to be adding a single character to the definition of $wgServer in LocalSettings.php.
$wgServer is used everywhere, I believe even for reader access, so I vote strongly against this change. ;-)
Normally the correct way of handling this is WebRequest::detectServer() which uses the protocol of the user's browsing state (if https, then https). I take this is a problem because the messages are decoupled between the event trigger and the recipient?
BTW, this sort of mediawiki discussion should probably be on a lis where much more experienced mediawiki devs can answer, so I'm moving it there.
That would change it in a few other places though, so sounds like 1 second of editing and 1 day of testing.
We could hack it in just for Echo, but that would either be hacky and specific to targeted installations or break on installs that don't have identical http and https urls.
BTW, my opinion is I'm okay with using http://... ($wgServer) right now for release and just capturing this request as a bug in bugzilla or in Trello for now. _______________________________________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________
Fabrice Florin Product Manager, Editor Engagement Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Donate to keep Wikipedia free: https://donate.wikimedia.org/