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 Fri, 25 Oct 2013 17:43:50 GMT
Closed #437. `je/42cc_6656`

- Create github app. Callback must be set to your host (e.g. https://sf-fortytwo-1030.sb.sf.net/).
It's important, since GitHub matches `redirect_uri` passed from authorications calls to it.
- Add keys to ini (see below)
- Go to project import page or individual tool import page for github. You'll be redirected
to github, asked to authorize app, then redirected back to form, and then you can run import
as usual

----

Ini options:

~~~~~
github_importer.client_id = <client_id>
github_importer.client_secret = <secret>
~~~~~

If app isn't set up (no app keys in config) it will still work, but use unauthorized, low
rate limit access


---

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

**Status:** code-review
**Labels:** import github 42cc 
**Created:** Fri Sep 13, 2013 08:12 PM UTC by Dave Brondsema
**Last Updated:** Thu Oct 24, 2013 12:43 PM 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