search

FraunhoferIOSB / FROST-Server

A Complete Server implementation of the OGC SensorThings API
https://fraunhoferiosb.github.io/FROST-Server/
GNU Lesser General Public License v3.0
198 stars 74 forks source link

Public exposure of root / DatabaseStatus web pages #93

Open jeremy303 opened 5 years ago

jeremy303 commented 5 years ago

I would think we shouldn't publicly expose the 'DatabaseStatus' page (and perhaps the root page) that FROST serves up. We can handle this via our reverse proxy but are their scenarios where it would be valuable to the operations team to have access to this page? Is there a different recommended approach?

Thanks!

mjacoby commented 5 years ago

I agree that it is not a good idea to make the "update database" functionality publicly accessible. However, for administrators and developers this might be useful information/function. As for now, FROST-Server does not provide any means to limit access to those pages. It needs to be managed via the web server/reverse proxy configuration upon deployment as you are doing now.

If you have any proposal how to address this issue (independent of the way access control is realized) feel free to post it here to discuss it. Even better, if you already have a solution you can add a pull request.

jeremy303 commented 5 years ago

Thanks, Michael.

One small suggestion would be to remove the "Database Status and Update" link from the main page. The rest of the main page content is fine, even desirable for a public audience. This way we could protect DatabaseStatus via proxy/server config, leaving the main page free to be served without admin-only links.

Perhaps DatabaseStatus could be hung off a new /admin route, which would allow for future growth of admin features, be easy to secure via proxy / server config and easy to remember.

hylkevds commented 5 years ago

When you use the authentication features, access to that page is restricted to the admin role. If you do not use the authentication features, you really are supposed to add security yourself. A user can't really do anything on the database update page, other than trigger a database update, which should not actually do anything in most cases. Without added security a user can also just delete everything, which is a much bigger issue than access to the database update page.

The "main" page is also just there for convenience after initial install, not something that end-users should rely on.

These things do need better documentation though. Since you're right that it's easy to forget to secure those. Moving admin-tools to /admin is a good idea!