v1.0.0 Roadmap about dietpi-dashboard

[MichaIng]

X-Download-Options can be skipped then indeed. Generally better to use HTTP headers instead of meta tags indeed 🙂.

[ravenclaw900]

Yeah, it was just a thought. Definitely have to fix the terminal login before v1.0.0 though. It came up because of the (mistaken) request for authentication at Fourdee/DietPi-Dashboard#2, where the user was surprised that the terminal auto-logged in.

[MichaIng]

@ravenclaw900
Is there something blocking an intermediate release from your end? The current nightly/main branch adds/fixes quite a few things compared to last stable release. Also we recognised that the stable aarch64 binary for some reason throws a segmentation fault on RPi 5, while the nightly works. Not sure how this can be, e.g. some change in the architecture/instruction set which is correctly handled with latest compiler, so that a simple rebuild with updated Rust would solve it as well? However, IMO worth it to push a new release better earlier than later. Also this allows us to switch to stable builds for RISC-V SBCs 🙂.

[MichaIng]

I'd add another task, adding common security headers for private websites:

X-Content-Type-Options "nosniff"
X-Frame-Options "sameorigin"
X-XSS-Protection "1; mode=block"
X-Robots-Tag "none"
X-Download-Options "noopen" # Internet Explorer only, AFAIK hence probably obsolete
X-Permitted-Cross-Domain-Policies "none" # needs testing with multiple backend nodes
Referrer-Policy "no-referrer"

Also CSP and PP headers could be added, to further tailor resource leading and client/browser feature usage to what the dashboard does/is intended to do, but this requires more investigation and testing, above the ones that should work as is.

[ravenclaw900]

The dashboard's already dead on IE, it makes heavy use of CSS flexbox. CSP is currently implemented through a <meta> tag on the HTML, though it's probably better to do with a header.

[ravenclaw900]

Just an idea, but instead of password protection on the terminal, how about just calling the login binary instead, so people can log in to either root or dietpi, and it will solve the current problem of the login dialog not working on the terminal page.

[MichaIng]

Sounds pretty reasonable. This would be even a reasonable default IMO, later probably with the option for autologin (with a specific user).

the current problem of the login dialog not working on the terminal page.

What you mean by this? Which login dialog when there is currently none intended?

[ravenclaw900]

The dialog works, but the terminal doesn't load, and requires a reload to get working. This is due to the fact that, since the websocket is connected to a PTY, it expects the first message to be the token if there's password protection, otherwise it quits.

[MichaIng]

Ah you mean the dashboard password input.

Now I get it, you mean to replace the general dashboard password protection on the terminal page with the console login prompt. Hmm, I think this is no good idea. User may not expect this and rely on a strong dashboard password and may have weak local UNIX user passwords or none at all. I thought this as an additional feature, allowing dedicated protection and different user logins for the terminal. But at least other user logins are not so much an argument since one can simply run sudo -u <user> bash to achieve the same from a root user session. Many users may however be more comfortable (and generally it is advisable) with using an unprivileged login user in general and calling sudo only where required. With login we give users the choice, an additional security layer but at the cost of additional required inputs 😉.

[lutfor-diu]

when to release?

[ravenclaw900]

Honestly, whenever I have time to finish the checklist. I don't want to make any guarantees right now.