View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0017363||mantisbt||authentication||public||2014-05-21 16:10||2015-04-21 06:13|
|Target Version||Fixed in Version|
|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. Its 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, Id get a free certificate and run the whole site over SSL and be done with it these days.
Reminder sent to: vboctor
I think thats 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 cant apply for GoDaddys 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 sites various components (tracker, forums, wiki, blog, etc)
Once were OK, Ill merge the 2 configs and setup an automated redirection so that any http request goes to https.
Not sure if its in your plan, but HSTS would be nice, so that we dont have a redirect from http to https from clients which have already visited our site.
Shouldnt be a problem setting up HSTS, its just an extra header to send.
I didnt 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.
<link rel=stylesheet type=text/css href=http://www.mantisbt.org/bugs/css/default.css />
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.
|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|