one endpoint protected AND public

[thedarkside]

Hi,
i want to realize a generic endpoint /cities to be public to everyone. The resultset would be [{id: 1, name: "xyz"}...]

But if a token was sent and is correct, the very same endpoint would additionaly return some user-context-specific attributes like {..., is_interesting: true}

Iam using winebouncers protected strategy and setting the endpoint to public by oauth2 false but that disables the token-check logic at all. resource_owner is nil even if the sent token is perfectly valid.

What i want is to check if resource_owner is set and then enhance the resultsets in this case.

Is it somehow possible?

[antek-drzewiecki]

Hi @thedarkside ,

The current implementation does not allow to make an endpoint both public and protected.
WineBouncer assumes that the endpoint has only one type of 'access modifier'.

What you could do, is to make a separate user context specific endpoint that extends the current endpoint or only shows interesting cities for that user. Whatever your implementation, you will end up with two endpoints.

If you really want one endpoint, your best start is you make an custom strategy in the WineBouncer::AuthStrategies:: namespace. You can always just hardcode true to the endpoint_protected? method as an test. Then the challenge would be to catch the exceptions that doorkeeper_authorize! throws.

There are some things to consider. I don't know if you are documenting the endpoint for public use. But there could be some issues with the current documentation tools that are around. They are mostly not context aware. The next thing are the responses. An dynamic response could lead to more implementation errors in parsing. Having two contexts for an endpoint could confuse the consumer of your API.

This is an interesting issue. Please let me know what you are going to consider to do.

[antek-drzewiecki]

closing due, inactivity.

[thedarkside]

@antek-drzewiecki i ended up with this patch documented here: #58 (comment)

This way winebouncer will always try to lookup a resource_owner if a token is present. Even if the endpoint is marked as public.
I am aware that this leads to issues with the documentation tools.
A cleaner way would be to create two endpoints with the same url marking one public and the other private (with oauth) and let winebouncer/grape decide which endpoint to call based on the presence of the token. In this scenario the documentation tools could list both endpoints with one marked as public and the other as private.
The main reason we picked this behavior was the reduction of complexity in the clients. Our system provides basic functionality to the public and more custom functionality to authenticated users. Authentication is optional.