anks 36 Posted October 30, 2014 Share Posted October 30, 2014 As far as I am aware, the following is true: - External users do not get the profile screen, just a login. (Non reverse proxy obviously) - Local users get the profile screen - Users accessing MB from localhost can login to any account without a password or an incorrect password. (A problem is reverse proxy is on the same machine as MB but there is a work around) Perhaps a simple solution would be: - A system wide option to disable the profile screen and require manual logins. - An option to require logins for localhost. (any reason why localhost is treated differently?) As far as I can see this change would be inline with the architecture and not affect existing apps. Very happy to code these changes if they fit the requirements? Link to comment Share on other sites More sharing options...
ebr 14898 Posted October 31, 2014 Share Posted October 31, 2014 #1 would require changes to all apps. #2 seems reasonable but does create a potential problem. The reason un-secured access is allowed via localhost is to allow you to get access to the server if you forget your admin password. We would have to have another way to do that. Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted October 31, 2014 Share Posted October 31, 2014 (edited) As far as I am aware, the following is true: - External users do not get the profile screen, just a login. (Non reverse proxy obviously) - Local users get the profile screen - Users accessing MB from localhost can login to any account without a password or an incorrect password. (A problem is reverse proxy is on the same machine as MB but there is a work around) Perhaps a simple solution would be: - A system wide option to disable the profile screen and require manual logins. - An option to require logins for localhost. (any reason why localhost is treated differently?) As far as I can see this change would be inline with the architecture and not affect existing apps. Very happy to code these changes if they fit the requirements? I ended up using the server name for my reverse proxy, rather than local host or 127.0.0.1 This will pick IPV6 or IPv4 local addresses and not loopback through the lan interface. and media browser doesnt think its a local request. MB also sees the remote IP's in its logs. What about the ability to bind MB to a specific interface? so that localhost and 127.0.0.1 wont respond to MB requests. Assuming that is what you are talking about you dont want people to be able to walk up to your MB machine and have full access? or! an option to set when you click the MB icon and go to browse or manage server you can set an option to make that link use the server name, rather than localhost.. Doesnt really help if people know how MB works, but may keep the kids from deleting your library? I think the bind option is probably easiest no? Edited October 31, 2014 by pir8radio Link to comment Share on other sites More sharing options...
ScottIsAFool 517 Posted November 1, 2014 Share Posted November 1, 2014 #1 would require changes to all apps. We used to have that anyway. I know mine did. There was a setting on the server, but it disappeared from the API I believe. @@Luke? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now