[WIP] OpenID connect client library - eyeing toward deploying keycloak #299
Conversation
| _web_driver.quit() # Close the browser window after tests | ||
|
|
||
| @pytest.fixture(scope="module") | ||
| def toy_flask(): |
There was a problem hiding this comment.
Unless there is some specific reason to run flask in a sub process, consider running it as described here https://flask.palletsprojects.com/en/3.0.x/testing/
In the past we've written tests like this to use a client with cookies, get the form, post the form with login and then get a protected page.
Now I'm seeing that the web_driver is requesting to flask running in the subprocess. This actually seems fine.
There was a problem hiding this comment.
Since we are spinning up a local flask in a subprocess, can we spin up a local keycloak too?
There was a problem hiding this comment.
Keycloak (KC) can run locally as a fixture, once what I want to test is more concrete. I needed to see what comes back from KC while changing the settings of KC - such as KC's notion of groups, roles, attributes you can define to the user. For example, I haven't been able to get the user's group in the oauth2 reply.
To make this a fixture, I need to run KC docker, and run a set of REST API calls to set up the settings (create the realm, client ID, client callback, etc.)
This PR is more for not losing work and exploring what I can do with KC. Right now, this is a test bench, and at some point, I will turn this into real regression test.
There was a problem hiding this comment.
Seems strange that the tests need the openid.arxiv.org server running. I would like for that to be in some kind of integration test that made it more clear that some new changes to the code were not working with an external service. Especially in the case where the externals service is down or at fault. I really don't want devs to have their tests fail on GH or on their laptops due to openid.arxiv.org being down or inaccessible. Our development process related to arxiv-base is already dev-unfriendly.
Here is an example of how auth testing for a log in has been done before: https://github.com/arXiv/arxiv-auth/blob/241169e13aa74b2fad57a8ba05ec3305ccff5ea0/accounts/accounts/tests/test_end_to_end.py#L213
I would not say it is ideal but it is self contained.
|
Can this run keycloak in a subrpocess just like it is running flask? Maybe with something like https://pypi.org/project/pytest-docker/ ? |
…er buffer size is 4k, and the claim == token being bloated is not a good idea.
|
The tests need to pass, if the tests are not yet ready they could have be marked to skip with a note as to why. |
…rovide alternate logout URL. claims gets id_token property.
2 - user_claims.py - token needs more diet. Gave up on including access and id tokens in the secret part. Only encrypt the user's property part. Access token is only needed for talking to Keycloak, and payload is for us. 3. Creating tapir session needs transaction. It is adding the tapir session successfully.
I'm not understanding why Keycloak made account has no "aud" while using legacy auth has it. In any rate, I think we don't care where the accounts come from. Token pack/unpack was totally busted, and now fixed.
…toke for it. The payload size is a bit tight.
…_id doesn't change while email may.
User claim's user ID "may not be integer" in rare occasion so be defensive. Fix the refresh token handling.
…er than the user claims.
… This saves about 1k in size. validate_access_token may not be RSA key. This isn't implementing the other key types but needs some research that which key type is the smallest.
The test in test_keycloak.py works, bet there are 2 fixture problems.
selenium web driver opens a web page in test mode, feed the user name/password. In short, the test mimics user interaction and I don't think this works in github's pytest run.
In general, how do we do the browser based testing?
Second is the keycloak itself. It is running in arxiv-development, and expect it to have a "testuser", so it may be okay but open to suggestions.
The test at the moment is minimal. It needs at least failing login, but that's after the above things sorted out, and hence this is a WIP.