Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.0.0 Roadmap #133

Open
18 of 24 tasks
ravenclaw900 opened this issue Jan 27, 2022 · 11 comments
Open
18 of 24 tasks

v1.0.0 Roadmap #133

ravenclaw900 opened this issue Jan 27, 2022 · 11 comments

Comments

@ravenclaw900
Copy link
Owner

ravenclaw900 commented Jan 27, 2022

Easy

Medium

Hard

Probably more to come, suggestions welcome.

@ravenclaw900 ravenclaw900 pinned this issue Jan 27, 2022
@MichaIng
Copy link
Collaborator

MichaIng commented Jan 28, 2022

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
Copy link
Owner Author

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
Copy link
Collaborator

MichaIng commented Jan 29, 2022

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

@ravenclaw900
Copy link
Owner Author

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
Copy link
Collaborator

MichaIng commented Feb 1, 2022

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
Copy link
Owner Author

ravenclaw900 commented Feb 1, 2022

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
Copy link
Collaborator

MichaIng commented Feb 1, 2022

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
Copy link
Owner Author

ravenclaw900 commented Feb 1, 2022

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.

@ravenclaw900 ravenclaw900 changed the title What to do before v1.0.0 v1.0.0 Roadmap Mar 9, 2022
@lutfor-diu
Copy link

when to release?

@ravenclaw900
Copy link
Owner Author

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

@MichaIng
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants