-
Notifications
You must be signed in to change notification settings - Fork 280
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
WebAuth Proof of Concept #1058
base: main
Are you sure you want to change the base?
WebAuth Proof of Concept #1058
Conversation
@wojtekmach here's the pr. |
Does everything else look fine? |
@ericmj , I have got an incomplete implementation in Schema. Whenever I run
|
It's hard to say without seeing what's being updated and when I try to run your branch it fails with a compilation error, but it looks like postgres is expecting an id/integer where you are passing a Key schema or Key params. I do notice that you are creating a Key with Keys.create and then embedding it in WebAuth which means it is stored in two places which we should try to avoid. Why does WebAuth need to store a Key? |
@ericmj, I need to return the key when the user attempts to access it in the last step. Since, the web auth requests are temporary, I cannot do a one to one association. I could return a url to access the key which I think right now is the best approach , but I am not sure if I can access a generated key via the api. |
Will the user need to fetch the key multiple times? Isn't it enough to create the key first when the user needs it and then not store it separately? |
@ericmj Well, the cli won't. On second thoughts, storing the generated key's primary id and accessing it when the user needs is doable. Wdyt? |
I think we should only generate the key when the user needs it and never let them access it again. We should not store the user secret of the key, if you look at the |
So, in the GenServer implementation, the request is deleted after few minutes, after which the user can't access the key. Anyways, we'll generate the key when the user attempts to access it like you said. |
@ericmj, I have pushed a complete implementation of WebAuth. Please review when you get the time. :) Note: It doesn't compile on this branch as I have made some changes to the Phoenix Router which I have not committed which it depends on (To determine the verification and access_key uri). |
@ericmj, also I don't plan to work on the controller so as to avoid doing redundant work in case the Schema implementation is not to your satisfaction. |
@Benjamin-Philip I noticed you pushed more commits. Let us know when it's ready for second review. |
Sure. I only fixed some minor stuff and still have to split the Web auth module into a context. I also have the remove the extra information. The thing is this and next month, I may not have much time to work on this PR. So updates are going to be slow. |
@ericmj, I hope there isn't a hurry? |
There is no rush :) |
@ericmj and @wojtekmach, I have split I'm not very sure if what I have done is the right way to go about it. (All the functions in the Context are impure, so I think it is.) |
@ericmj, and @wojtekmach, please review the Note: Changes to HexpmWeb is not yet review ready. |
Co-authored-by: Eric Meadows-Jönsson <eric.meadows.jonsson@gmail.com>
Co-authored-by: Eric Meadows-Jönsson <eric.meadows.jonsson@gmail.com>
Previously, the browser user agent was used to creating an audit. This had the following problem: - It gave a false sense on whose request the key was generated. - The user agent was stored under the field `audit` which caused confusion. This commit changes the WebAuth flow so that the client's user agent (that is on the `access_key` action) is used to create a key.
WebAuth requests made a day (i.e. stale) before should not be supported. This commit adds support for the `submit` and `access_key` actions to filter out stale requests when querying the DB.
This commit adds a release task that will remove all stale requests from the database.
This commit adds the RFC that was used as a reference when developing the WebAuth flow as a comment
The audit data format changed and required an ip address. This commit updates the WebAuth PR to use this new format.
24f988f
to
c3c1eee
Compare
@ericmj and @josevalim, could we request someone else to review this PR as well? This PR went out of date and had errors due to changes in main. I think we should try to merge this PR as soon as possible to prevent such errors - updating this PR to work with main periodically may prove a hassle to me and the reviewers. |
Also I rebased this PR to main. |
The following is a Proof of Concept for web auth.
Closes #1024