Apache Allura™

• Got an AttributeError: access_token error when authenticating an API endpoint request using an access token, I think that's because of using request instead of req in rest.py:510
• For some reason my UI froze when clicking the Register new application for OAuth2. I ended up clicking the button many times and when the UI was responsive again, it created multiple clients with the same name. Looks like UniqueOAuthApplicationName only validates against OAuth1 collections, so maybe should create an OAuth2 version?. That's if we're enforcing unique client names.
• Probably we also want to enforce that the user inputs at least one redirect URL, they seem to be an important part of OAuth2 security-wise.
• Should we display the Authorization Code and Access/Refresh tokens along with the client app information, in case the user for some reason loses those codes?

• good catch, I had this correct earlier but it didn't get merged properly so I had to redo it on this branch and missed that bit. Fixup pushed now.
• hmm that is interesting. UniqueOAuthApplicationName checks globally so you couldn't have 2 clients named "test". Do we want this? The only reason I can think of is to prevent confusion if there are multiple people with "Zapier" clients, you might wonder which one is the "real" one? But you only see the authorization page for the client apps that you engage with, you'll never know if there's other ones or not. So I kinda think this is an unnecessary validation.
• yea, maybe? The feedback I posted on your merge request is related to this too, if wiki-copy.py could be used without a redirect. Also what about when we generate personal bearer tokens? The OAuth1 approach has them derived from a client, so you'd have to make a client with a dummy redirect just to get a bearer token. Maybe we should make the process simpler and make the bearer token not even related to any client app at all? Not sure if that would work or not.
• I was thinking we don't need to show codes & tokens to the user, since the user actually never sees them earlier either. It is the 3rd-party "client" is who gets those tokens and uses them. However! Once we start doing personal bearer tokens, we'll definitely want to show the token then. The oauth1 code has an is_bearer flag to know if the token is a personal one or one that a client app got authorized to use

I rebased against master and made one more fixup:

• remove UniqueOAuthApplicationName usage within oauth2
• make redirect URI required, since oauthlib seems to require it. In the rare case of something like wiki-copy.py which isn't a web app, they'll have to put something in, even if they don't use it.

All changes look good to merge.