You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Somewhat yes. Consider the following REST resource:
GET, POST: /articles
In this case, you need to be authenticated to post an article. However to get all the articles, you can and don't have to be authenticated. If you are not, you will receive only the public articles. If you authenticate, you will also receive those, that you have permission to view.
Using Kotlinx RPC, I would imagine that you would create an ArticleService, that would have the getAll and post methods. However how do you handle the authentication? What I have understood is that when you use the Ktor server implementation, you can protect the entire route, however, that has many downsides:
The above scenario is not possible.
You cannot have more services under one route, where some need auth and some don't (this maybe is not that of a downside)
You cannot get the authentication details inside the RPC method. (or I am not aware how?)
If the authentication is done using the RPC itself, then it is done in the middle of the WebSocket connection, so you would have to remake the initial websocket request, which doesn't make sense. The primary use-case of RPC seems to be Web SPA, where single connection is iconic.
Describe the solution you'd like I am not entirely sure how this library is implemented, so keep that in mind please.
Add a feature, similiar to http headers. Each call, would apart from what service is being called and what are the arguments also be able to carry additional data, that could contain the authentication information.
This would also be a helpful addition overall, that you could pass additional context/state data. I am not entirely sure, whether the authentication should be part of this additional data feature, or it should be handled seperately. Handling it seperately might have an adventage, where some transport implementation can have specific custom ways of handling authentication.
Describe alternatives you've considered
I have already described above.
Additional context
I have read all the issues related to authentication, however to my understanding the provided solutions do not solve above problems.
The text was updated successfully, but these errors were encountered:
It depends on the posibilities of the plugins. But yes, if the plugins would be able to modify the actual request, then it should be possible to make an Authentication plugin. And actually I think making it an extension plugin is a great idea, similiar to Ktor's.
Hi, @tomhula! Thank you for the feature request. We are thinking about protocol enhancements, and we'll take this into consideration during the design. Either it would be done by plugins, or by a separate feature - I don't know yet
Is your feature request related to a problem? Please describe.
Somewhat yes. Consider the following REST resource:
GET, POST: /articles
In this case, you need to be authenticated to post an article. However to get all the articles, you can and don't have to be authenticated. If you are not, you will receive only the public articles. If you authenticate, you will also receive those, that you have permission to view.
Using Kotlinx RPC, I would imagine that you would create an ArticleService, that would have the getAll and post methods. However how do you handle the authentication? What I have understood is that when you use the Ktor server implementation, you can protect the entire route, however, that has many downsides:
Describe the solution you'd like
I am not entirely sure how this library is implemented, so keep that in mind please.
Add a feature, similiar to http headers. Each call, would apart from what service is being called and what are the arguments also be able to carry additional data, that could contain the authentication information.
This would also be a helpful addition overall, that you could pass additional context/state data. I am not entirely sure, whether the authentication should be part of this additional data feature, or it should be handled seperately. Handling it seperately might have an adventage, where some transport implementation can have specific custom ways of handling authentication.
Describe alternatives you've considered
I have already described above.
Additional context
I have read all the issues related to authentication, however to my understanding the provided solutions do not solve above problems.
The text was updated successfully, but these errors were encountered: