v1.0.0 Roadmap

[ravenclaw900]

Easy

• [x] Add common private website security headers (https://github.com/ravenclaw900/DietPi-Dashboard/issues/133#issuecomment-1024333027) (https://github.com/ravenclaw900/DietPi-Dashboard/commit/52f8e1643858e479b29b46e44acf4bcb8b056e36)
• [ ] Allow naming backend nodes/show in title (#75)
• [x] Version nightly releases by commit hash
• [x] Add config file setting for terminal auto-login or manual login (#195) (#202)
• [x] Add customizable token timeout (requires biscuit) (https://github.com/ravenclaw900/DietPi-Dashboard/issues/155#issuecomment-1037375930)
• [x] Test serde without serde_derive and/or serde_json (#186)
• [ ] Allow setting subnet to run on

Medium

• [x] Add more debug messages (#276)
• [x] Make main websocket keep trying to reconnect (#325)
• [x] See if it's possible to switch to biscuit library for JWT creation and validation (can't require serde)
• [x] Get CPU temp (Maybe switch back to psutil, can be augmented with other crates for missing functionality). (#36)
• [x] Add a message showing if updates are available (#201)
• [ ] Allow updating-in-place
• [x] Switch to more lightweight chartist or uplot chart library
• [x] Use select! instead of spawning threads on page visits
• [ ] Allow setting path for reverse proxies
• [x] Compress files before storing in binary (#263)

Hard

• [x] Fix file browser (#123)
• [x] Fix terminal login dialog (#198)
• [x] Add more error handling, use less unwrap (#236)
• [x] Fix terminal freezing (#70)
• [ ] Allow using drives other than / in the graph. (https://dietpi.com/blog/?p=1137#comment-581)
• [x] Allow cancelling of file browser (e.g. loading /dev, downloading large file) (#270)
• [ ] Add links page

Probably more to come, suggestions welcome.

[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.

[MichaIng]

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

[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 😉.

[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 https://github.com/Fourdee/DietPi-Dashboard/issues/2, where the user was surprised that the terminal auto-logged in.

[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.

[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 🙂.