[GH-ISSUE #179] Feature request: Add access control to web interface #3409

Closed
opened 2026-03-20 23:05:19 +01:00 by sascha_hemi · 4 comments
Owner

Originally created by @jum0n on GitHub (Dec 14, 2023).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/179

Originally assigned to: @nlimper on GitHub.

Is your feature request related to a problem? Please describe.
Security is everyone's problem? ;)

Describe the solution you'd like
Would really like a password for the web interface to make it more secure.

Originally created by @jum0n on GitHub (Dec 14, 2023). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/179 Originally assigned to: @nlimper on GitHub. **Is your feature request related to a problem? Please describe.** Security is everyone's problem? ;) **Describe the solution you'd like** Would really like a password for the web interface to make it more secure.
sascha_hemi added the enhancement label 2026-03-20 23:05:19 +01:00
Author
Owner

@Calimerorulez commented on GitHub (Dec 21, 2023):

Good idea; I like to add a request for user access control. One of my kids would like to updated his own tag, but I do not want to give him full access to the web interface...

<!-- gh-comment-id:1866906650 --> @Calimerorulez commented on GitHub (Dec 21, 2023): Good idea; I like to add a request for user access control. One of my kids would like to updated his own tag, but I do not want to give him full access to the web interface...
Author
Owner

@milo526 commented on GitHub (Jan 11, 2024):

I believe these 2 feature requests (by @jum0n and @Calimerorulez) are quite different.

Adding a plain password to the UI is fairly trivial.
Adding accounts and being able to assign them to tags is quite a bit more difficult.

Only limiting the web-interface will not provide any real security since the AP's API can still be interacted with in different methods (but might keep someone's kids out of the UI)

I believe it's dangerous to introduce security features that are more show than actual security since they might give people a false sense of security.

I'd love to help think about what is a good tradeoff given the hardware limitations we are dealing with and the fact that this should probably still be considered a "hobby" project.

<!-- gh-comment-id:1886946748 --> @milo526 commented on GitHub (Jan 11, 2024): I believe these 2 feature requests (by @jum0n and @Calimerorulez) are quite different. Adding a plain password to the UI is fairly trivial. Adding accounts and being able to assign them to tags is quite a bit more difficult. Only limiting the web-interface will not provide any real security since the AP's API can still be interacted with in different methods (but might keep someone's kids out of the UI) I believe it's dangerous to introduce security features that are more show than actual security since they might give people a false sense of security. I'd love to help think about what is a good tradeoff given the hardware limitations we are dealing with and the fact that this should probably still be considered a "hobby" project.
Author
Owner

@nlimper commented on GitHub (Jan 11, 2024):

OpenEpaperLink is for hobby, and not designed to be safe. Take the 'open' in OpenEpaperLink very literally. ;-)

  • The procol between AP and tags is not encrypted or secured.
  • The UDP multicast messages between the AP's are not encrypted or secured.
  • The management website is not encrypted.
  • De database can be download by anyone.
  • All files in the AP file system can be read and written by anyone in your network.

So, like @milo526 corretly states. it makes no sense in securing the management website any more than a basic http password.
Adding a basic password (http basic authentication) can be done easily (https://github.com/me-no-dev/ESPAsyncWebServer?tab=readme-ov-file#serving-static-files-with-authentication). Feel free to add it!

<!-- gh-comment-id:1887058156 --> @nlimper commented on GitHub (Jan 11, 2024): OpenEpaperLink is for hobby, and not designed to be safe. Take the 'open' in OpenEpaperLink very literally. ;-) - The procol between AP and tags is not encrypted or secured. - The UDP multicast messages between the AP's are not encrypted or secured. - The management website is not encrypted. - De database can be download by anyone. - All files in the AP file system can be read *and* written by anyone in your network. So, like @milo526 corretly states. it makes no sense in securing the management website any more than a basic http password. Adding a basic password (http basic authentication) can be done easily (https://github.com/me-no-dev/ESPAsyncWebServer?tab=readme-ov-file#serving-static-files-with-authentication). Feel free to add it!
Author
Owner

@Calimerorulez commented on GitHub (Jan 12, 2024):

Agreed :-)

<!-- gh-comment-id:1888686059 --> @Calimerorulez commented on GitHub (Jan 12, 2024): Agreed :-)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#3409