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

Refactor authentication #178

Open
pmeier opened this issue Nov 8, 2023 · 2 comments
Open

Refactor authentication #178

pmeier opened this issue Nov 8, 2023 · 2 comments
Assignees
Milestone

Comments

@pmeier
Copy link
Member

pmeier commented Nov 8, 2023

Currently, the basic auth, i.e. username / password, is hardcoded in the UI. We did that to meet our presentation deadline. In the aftermath however, we need to lift this and actually implement the UI part as part of the authentication class:

class Authentication(abc.ABC):

This would enable us and users to switch the authentication method smoothly.

@pmeier pmeier added this to the 0.2.0 milestone Nov 27, 2023
@pmeier pmeier removed this from the 0.2.0 milestone Feb 2, 2024
@pmeier pmeier added this to the 0.3.0 milestone Mar 18, 2024
@pmeier
Copy link
Member Author

pmeier commented Mar 18, 2024

We need to tackle this as this is a major blocker for anyone who wants to use Ragna in production. There is currently no way to use the UI with any login method other than username and password. However, to be able to log in with OAuth or the like, we cannot keep our current login endpoint on the REST API. Thus, we need a larger refactor here.

The scheme that I have in mind is that the API gets a GET /login endpoint that serves user defined HTML. From there the user can either hit POST /login, i.e. for form data when logging in with basic auth, or GET /oauth-callback if such a scheme is used.

Internally, both endpoints funnel back into a user defined function that validates the login and returns the username that we ultimately store in our DB.

We then redirect to a yet to be designed HTML page that gives the user the option to forge a JWT that includes the user ID.

This JWT is then used as authorization header for the API as well as cookie for the UI.

@pmeier pmeier changed the title Refactor authentication in the UI Refactor authentication May 16, 2024
@pmeier pmeier self-assigned this May 16, 2024
@pmeier
Copy link
Member Author

pmeier commented May 16, 2024

Blocked by #417. Acceptance criteria:

  • Login method must be user configurable through an Auth object that needs to allow basic auth (username / password) as well as OAuth
  • Login must be possible regardless of the deployment mode, i.e. just REST API, just web UI, or both
  • API should be accessible through an API token that can be generated after being logged in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

1 participant