Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication #221

Open
tomhula opened this issue Nov 3, 2024 · 3 comments
Open

Authentication #221

tomhula opened this issue Nov 3, 2024 · 3 comments
Assignees
Labels
feature New feature or request

Comments

@tomhula
Copy link

tomhula commented Nov 3, 2024

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:

  1. The above scenario is not possible.
  2. You cannot have more services under one route, where some need auth and some don't (this maybe is not that of a downside)
  3. You cannot get the authentication details inside the RPC method. (or I am not aware how?)
  4. 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.

@tomhula tomhula added the feature New feature or request label Nov 3, 2024
@lsafer-meemer
Copy link

Could this be fixed with: #150 ?

I am not a contributor, this is just my opnion

@tomhula
Copy link
Author

tomhula commented Nov 6, 2024

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.

@Mr3zee
Copy link
Collaborator

Mr3zee commented Nov 6, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants