-
-
Notifications
You must be signed in to change notification settings - Fork 421
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
Reformat Examples #468
Comments
After thinking about this for a while I realized the only way to implement it would be to have accounts registered to this library to obtain client id/keys. There seems to be a section in GitHub settings that might be able to store this data securely. Not sure if it is a good idea to move forward though. Who would be owner of the accounts of the resource providers? Will leave this up for a little while longer. |
Would be very interesting to see it for real. If stored securely, I suppose it is safe to put personal tokens there.. Note it can be interesting to start with a skeleton/example/documentation section on how to create one of these sections. That way everyone could add his own provider tests. |
I have added python code in a separate file, and it makes maintenance and copy/paste (!!) much easier. See https://requests-oauthlib.readthedocs.io/en/latest/examples/native_spa_pkce_auth0.html The next step would be to add unit test with environment variables and integrated into GitHub Actions. |
Closing as it is now part of 1.4.0 / #530 |
Am interested to receive feedback on reformatting the examples to make them easier to maintain, and setup. Currently I noticed there are a few issues with the current format of the examples:
.rst
file, clean it, and manually update.I would purpose that the structure of the examples adopt a more modular suite approach.
Of course this structure is just an example to transmit and overall idea. Different testing/config frameworks could be applied as well. While a departure from the simple examples setup from before this offers several benefits:
Draw backs to this approach is that the examples themselves become a little heavy.
Interested in feedback. Willing to take on this effort if Repo Owners/Admins would allow for the github secrets feature be implemented to store test account api credentials.
The text was updated successfully, but these errors were encountered: