Do not expose admin username in frontend

[developerfromjokela]

Hello!
motionEye seems to expose admin username in its HTML as javascript variable.
I think this is a potential security risk for brute-force and/or dictionary attacks towards the login system.

What was/is purpose of keeping that variable in HTML?

[G2G2G2G]

This has nothing to do with brute force or dictionary attacks in any way.
data logging/sniffing/reading sure

[developerfromjokela]

It has. If you don't expose your username, they cannot login even if they had correct password.

[developerfromjokela]

It makes that job easier

[MichaIng]

What was/is purpose of keeping that variable in HTML?

It is the way how it is passed from the backend to browser's JavaScript to check whether the current user is the admin user, to show/hide enable/disable certain GUI elements:

• Set here via inline script, generated by backend: https://github.com/motioneye-project/motioneye/blob/c7d86c6/motioneye/templates/main.html#L89
• Used for this function in main JavaScript, executed in browser: https://github.com/motioneye-project/motioneye/blob/4249e44/motioneye/static/js/main.js#L398

However, I agree this is not so awesome. The admin username cannot be changed via GUI, but at least manually via config file. Since it is not used anywhere else in the frontend, it makes more sense to pass an "isAdmin" flag instead of the name. Even smarter would be to apply an admin or non-admin class to admin-only HTML elements right with the backend to have them shown/hidden in the first place, without needing to toggle classes via JavaScript, making even passing this flag obsolete.

[MichaIng]

Reviewing this since we have a PR to make the admin username editable again: #3298

Just to make clear: since it is hardcoded right now (though possible to manually change in config files), this currently doesn't make login more or less secure. But with above PR, things change.

Apart of the actual admin username, there is another variable that has as value only admin or normal, independent of the username. So it indicates the user type, not its name, much better suited for what is aimed in the frontend.

Just need to assure it is available or passed through to the Jinja2 HTML builder context. Generally, a tornado feature, there is [self.current_user](https://www.tornadoweb.org/en/stable/web.html#tornado.web.RequestHandler.current_user), generated here: https://github.com/motioneye-project/motioneye/blob/dev/motioneye/handlers/base.py#L102
So that would also serve as indicator for the login status itself.

Checking further, I guess it just needs to be passed here, just like the version variable: https://github.com/motioneye-project/motioneye/blob/dev/motioneye/handlers/base.py#L86-L94

[MichaIng]

Saw just now the conversation was locked. Unlocked, since it is a perfectly valid concern with easy fix AFAICS.