incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Bondarenko" <jetm...@users.sf.net>
Subject [allura:tickets] #6656 Github oauth application
Date Thu, 24 Oct 2013 09:43:51 GMT
Workflow you described is good and looks like github's web application flow. http://developer.github.com/v3/oauth/

But implementing it will require additional interaction with user, such as redirecting to
github to authenticate/allow access, when user accessing import page and has no oauth token
yet. Is that okay with you?

I personally prefer the above, but there also a couple of options to implement server-server
auth, that doesn't require interaction with user:

1. send client_id and client_secret (oauth app's keys) with every request
2. get auth token programmatically http://developer.github.com/v3/oauth/#non-web-application-flow

(1) is very simple to implement and it increases rate limit, but the downside is we'll have
rate limit for per entire app, not per user, as with tokens.

(2) requires basic auth, so we should ask user for his github credentials, which is bad, or
create github user for allura instance and put credentials to ini, which also seems pretty
bad.


---

** [tickets:#6656] Github oauth application**

**Status:** in-progress
**Labels:** import github 42cc 
**Created:** Fri Sep 13, 2013 08:12 PM UTC by Dave Brondsema
**Last Updated:** Mon Sep 30, 2013 11:25 AM UTC
**Owner:** nobody

To avoid low rate limits for anonymous API access, we should use an oauth app.  http://developer.github.com/v3/#rate-limiting

As best I can tell https://pypi.python.org/pypi/requests-oauthlib is the best oauth v2 library
to use.   (The "oauth2" library we already use, despite its name, only is for oauth v1) It's
license is BSD/MIT style, based on the very good 'requests' library, has good docs and has
an active git repo.

I am not super familiar with oauth v2 and github's setup, but based on what I know, here's
how I think it should work.  Each Allura instance (e.g. your development host, SourceForge,
etc) will need to set up a their own Github OAuth App.  Then those keys can be placed in the
`ini` file.  Our github importer code will then do the oauth flow to authorize the user requesting
an import.   No [scope](http://developer.github.com/v3/oauth/#scopes) is necessary since we're
just doing public readonly fetching.  We should store the appropriate user tokens (via `user.set_tool_data`)
so that they are available for the background task, and also can be re-used if the user wants
to run another import.

This should all go through a shared mechanism (e.g. override the base `ProjectExtractor.urlopen`
in `GitHubProjectExtractor`) so that it's used for all github related API access.  This code
should also check the rate limit values and when it reaches the limit, log a warning, and
sleep for the amount of time needed until the limit resets).

Of course, we can modify this as needed if my understanding of github oauth isn't correct.




---

Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options.
 Or, if this is a mailing list, you can unsubscribe from the mailing list.
Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message