Implementing block and unlock method to allow access control

[tribal-tec]

Missing unit test. Then you will have to find a better solution for the 'localhost' problem. Maybe a whitelist to block() or similar. Otherwise this is OK.

[eile]

This does not look right, esp. the fact that it makes an exception for localhost!?

I guess this is for the Tide screen lock - why not layer it there?

[rdumusc]

Correct, it is for the Tide screen lock and I had the same reaction as you initially.

• I perfectly agree that the localhost exception should be removed, unfortunately this will pose another problem in the Tide case because the launcher actions will be blocked too, so we need another solution for that.
• The rationale for having this functionality in the server is that it would be quite difficult to try to replicate this feature at the application level. Each of the callbacks with a RESTFunc could return a 403 when locked, but it's easy to forget one somewhere. Old-style callbacks could only return false, resulting in a 404. For the Serializable objects it even is more problematic, the only solution would be to deregister their PUT method, also resulting in a 404.

[eile]

The http server in Tide could extend the ZeroEQ one, implementing the 403 in a generic way for the restricted use case needed?

[rdumusc]

theoretically yes but not clear how to do it. Would need to add a protected virtual function for that specific purpose - right now_processRequest() is well hidden in the pimpl to which derived classes have no access.

[rdumusc]

Will be implemented by an http::Server subclass in Tide