Closed nikochiko closed 1 year ago
A couple of suggestions:
On Wed, Oct 19, 2022, 11:47 PM Kaustubh Maske Patil < @.***> wrote:
Auth will be done using oauth with github as the provider.
We will need
- a new table to store user data
- a configuration file for keeping oauth secrets (client key, client secret)
- a way to extend the existing Flask app exposed by core.app.wsgi
Table
This raises one more question: should the schema for this be merged along with the core schema? or should this be kept separate and applied to the same database? I think that for now we should keep a separate schema file for this so that we can re-use the core part for other projects without any changes to the schema. It would be good to have user tables in core to track progress, so we can add that once we have a good idea of what a generic-enough schema would be.
Schema should be like this:
CREATE TABLE user { id integer primary key, username text, ip_address text };
ip_address should ideally be separate from the user table, but I don't want to make any changes to the app table provided by the core where IP address isn't generic enough to be included. Moreover, the ip-address won't be of much use once we set the DNS entry to link it to a hostname. Configuration
We shouldn't use the config key in tasks.yml because we will be pushing it to version control. We should instead use environment variables that can be set in Hamr's config. Extending Flask app to add endpoints
This should be simple enough. We can do something like:
in wsgi.py
from selfhosting import app as tm # tm for treadmill app = tm.wsgi # as per hamr convention of wsgi:app @app.route("/auth/github/initiate")def initiate_oauth(): ...
Extending Templates
We would need to do this to add a "Connected! You can close this and go back to your droplet now" page or later for landing-page.
I think a good idea would be to have another templates folder outside core (in top-level) where this overrides would reside.
We should cut up the templates in core into appropriate blocks so that they would make sense on their own and help with extension.
— Reply to this email directly, view it on GitHub https://github.com/pipalacademy/self-hosting-101/issues/6, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAB3ELPJDZCGTLDNY62Y4TWEA3NBANCNFSM6AAAAAARJMIVXI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Backend for authentication has been added.
These are the endpoints
/auth/github/initiate
- redirect to github oauth/auth/github/callback
- return URL from github/auth/me
- return a JSON response with the current user's username and node's IP-address/auth/logout
- logoutThese configuration parameters need to be set in the environment:
GITHUB_CLIENT_ID
GITHUB_CLIENT_SECRET
SECRET_KEY # for session-cookies. once authenticated with github, user's username is kept in session
SERVER_NAME # for redirect URI from github
Sessions are also to be used to store the IP address when it is received at http://self-hosting-101.pipal.in/connect (https://github.com/pipalacademy/self-hosting-101/issues/5)
In Hamr, the config.yml can be set to:
flask_secret_key: abcd123
flask_server_name: self-hosting-101.pipal.in
flask_preferred_url_scheme: https # defaults to localhost
github_client_id: abcd123
github_client_secret: xyzw321
A similar config is being used for self-hosting-101.pipal.in
. This is the OAuth app in use: https://github.com/organizations/pipalacademy/settings/applications/2022026
Another OAuth app is created with redirect URL as http://localhost:5000 for local testing
Next steps:
Further UI changes such as a link to user's own app or making it the default should be another issue.
Auth will be done using oauth with github as the provider.
We will need
core.app.wsgi
Table
This raises one more question: should the schema for this be merged along with the core schema? or should this be kept separate and applied to the same database? I think that for now we should keep a separate schema file for this so that we can re-use the core part for other projects without any changes to the schema. It would be good to have user tables in core to track progress, so we can add that once we have a good idea of what a generic-enough schema would be.
Schema should be like this:
ip_address
should ideally be separate from the user table, but I don't want to make any changes to the app table provided by the core where IP address isn't generic enough to be included. Moreover, the ip-address won't be of much use once we set the DNS entry to link it to a hostname.Configuration
We shouldn't use the
config
key intasks.yml
because we will be pushing it to version control. We should instead use environment variables that can be set in Hamr's config.Extending Flask app to add endpoints
This should be simple enough. We can do something like:
Extending Templates
We would need to do this to add a "Connected! You can close this and go back to your droplet now" page or later for landing-page.
I think a good idea would be to have another
templates
folder outsidecore
(in top-level) where this overrides would reside.We should cut up the templates in core into appropriate blocks so that they would make sense on their own and help with extension.