View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0017363||mantisbt||authentication||public||2014-05-21 16:10||2020-01-18 12:21|
|Summary||0017363: Authentication is done using http (non-ssl) and passwords appear in plaintext.|
When logging in mantis, the login is done using http instead of https. Passwords appear in plaintext on the network, and can be captured by someone other than the user.
|Steps To Reproduce|
Btw, mantisbt is a great tool. It's the only bugtracking system I found that could be installed on a hosted server, and the installation is really simple.
|Tags||No tags attached.|
Obviously if you hosting Mantis yourself, use HTTPS/SSL
In terms of Mantisbt.org, I completely agree - personally, I'd get a free certificate and run the whole site over SSL and be done with it these days.
Reminder sent to: vboctor
I think that's a sensible thing to do. Can you take care of obtaining a certificate ? I can set it up on the server.
I think you should do this for mantisbt.mobi as well (although you can't apply for GoDaddy's open source offer for this).
I will sort out the certificate.
SSL should now be operational - https://mantisbt.org
For now I have it setup with two distinct configs, to give us time to test and see if there are any issues with the site's various components (tracker, forums, wiki, blog, etc)
Once we're OK, I'll merge the 2 configs and setup an automated redirection so that any http request goes to https.
Not sure if it's in your plan, but HSTS would be nice, so that we don't have a redirect from http to https from clients which have already visited our site.
Shouldn't be a problem setting up HSTS, it's just an extra header to send.
I didn't notice it last night (it was late...) but https seems to cause issues with rendering the bugtracker, looks like the css is not loaded, not sure why.
Many assets are loaded using http, e.g.
<pre><link rel="stylesheet" type="text/css" href="http://www.mantisbt.org/bugs/css/default.css" /></pre>
This is the probable cause of the breakage
Yes I noticed that after posting.
So the root cause is
Anyway the fix is to dynamically set the protocol when initializing $g_path. Should work now.
As a side note, I wonder why Firefox just blocked the CSS and did not give any "mixed content" warning, and also Firebug just silently failed to load the file without reporting anything in the Net panel or the console.
If I'm not mistaken, this has been fixed for a long time, right?
Correct, this should now be marked resolved (the session in using https as I write this, and the certificate is current/valid).
|2014-05-21 16:10||doug_stevens||New Issue|
|2014-05-21 18:30||grangeway||Note Added: 0040614|
|2014-05-21 19:05||dregad||Note Added: 0040617|
|2014-05-22 00:54||vboctor||Note Added: 0040619|
|2014-05-22 00:55||vboctor||Assigned To||=> vboctor|
|2014-05-22 00:55||vboctor||Status||new => assigned|
|2014-05-22 19:11||dregad||Assigned To||vboctor => dregad|
|2014-05-22 19:14||dregad||Note Added: 0040629|
|2014-05-23 02:48||rombert||Note Added: 0040630|
|2014-05-23 04:26||dregad||Note Added: 0040631|
|2014-05-23 04:33||rombert||Note Added: 0040632|
|2014-05-23 05:00||dregad||Note Added: 0040633|
|2014-05-23 05:01||dregad||Note Added: 0040634|
|2020-01-07 16:31||rogueresearch||Note Added: 0063378|
|2020-01-07 16:39||doug_stevens||Note Added: 0063380|
|2020-01-07 17:23||atrol||Status||assigned => resolved|
|2020-01-07 17:23||atrol||Resolution||open => fixed|
|2020-01-18 12:21||atrol||Status||resolved => closed|