Potential security flaw with settings login

[j-broo]

Once you have logged in, you can still get to the settings URL even if you navigate away from the settings page.

We may need a logout button or a session timeout on settings.

[grae22]

Currently it's session based, not sure when it expires - will check it out.

[grae22]

Session now expires after 5 mins.

[j-broo]

Waited on setting page for 10 min, was not kicked off. Could still edit settings.

[grae22]

Ah yeah currently it won't kick you off, but after 5mins you shouldn't be able to enter the address and access it. I'll add a page refresh that'll kick you off after a while.

[j-broo]

Cool. Currently if you get stuck on the login page, you have nowhere to go without a PW. Perhaps boot the user back to default.aspx?

[grae22]

Should now bounce back to default page after 5 mins of no activity on settings or import/export page.

[j-broo]

Didnt seem to work on settings page.. left it for 20 min, didnt kick me to default. Used mobile browser and azure page. When i clicked on "edit" it did bounce me to login screen, bit having seen the password by then it made no difference. Perhaps we should * the password on display? This is probably all overkill at this stage...

[grae22]

Just made this change in master, I'll push it to the experimental site and test it there.

[grae22]

Mmm seems to work.

[grae22]

'ing out the password field would be tricky (with the current implementation) to just out that setting's value.

[j-broo]

Tested auto-logout. Works. Nice addition of the 'back' link on the login screen. I think *ing out the password can be left for a future major release, if it's ever warranted.

Suggestion for version 1: Display password with base64 encoding? Obfuscated at least. Yay/nay?

[grae22]

Yeah like the obfuscation idea.

[grae22]

Turns out it was easier just to *** it out.

[j-broo]

Works fine. Enough security for initial release.