Skip to content
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

ability to assign roles/permissions to api keys #290

Open
bninja opened this issue Mar 28, 2013 · 12 comments
Open

ability to assign roles/permissions to api keys #290

bninja opened this issue Mar 28, 2013 · 12 comments

Comments

@bninja
Copy link
Contributor

bninja commented Mar 28, 2013

currently if i create an api key it has full access to the api.

it's useful to be able to create api keys with a limited set of permissions (either by assigning the api key a role or by explicitly setting permissions). this would allow me to e.g. hand out limited permission keys to 3rd parties or give team members limited control over the dashboard.

additionally i'd like to be able to see:

  • which triggered events (e.g. which one was used to cancel a credit)
  • which where used to access the api (e.g.which one was used to read transaction data).
@mjallday
Copy link
Contributor

Would oAuth be a good solution here? It allows assigning permissions based on URIs (scope) and would allow setting an expiration on keys when they are handed out. It would also make it easy for 3rd party integration.

@bninja
Copy link
Contributor Author

bninja commented Mar 29, 2013

@mjallday sounds like what oauth (2.0?) was designed for, so yea lets explore using that. i guess the dashboard would be the initial consumer so lets validate our choice that way.

@trea
Copy link

trea commented Apr 15, 2013

I'd love to see OAuth 2 implemented! +1

@mjallday
Copy link
Contributor

We're getting some love for this issue over on the balanced-dashboard as well

@benblair
Copy link

+1 We've seen some reluctance on the part of new sellers on our marketplace to trust our assertion that we have the buyer's funds on hand during a transaction. I think it would go a long way if they could verify directly with Balanced that payment for that particular transaction had been received.

@steveklabnik
Copy link
Contributor

This is being worked on, but hasn't been finished yet!

@ariofrio
Copy link

Any progress on this? I think this would be not only really useful, but serve as a security feature by limiting what an attacker can do if they gain control of a server that only has access to a limited-permission API key.

@mjallday
Copy link
Contributor

mjallday commented Jan 7, 2015

here's the scenarios that we're immediately attempting to address:

@mahmoudimus and I were discussing the implementation details on #667 yesterday, i'll attempt to give an update there with regards to those.

@kyungmin
Copy link

kyungmin commented Jan 7, 2015

read only for a customer (e.g. let my customer see what i'm storing for them) - #290 (comment)

This seems to require a larger effort. The dashboard currently shows a lot of information that's not relevant for them in the chrome (i.e., sidebar menu items, total balance). It means that we need to provide a separate dashboard view specifically for sellers.

@mjallday
Copy link
Contributor

mjallday commented Jan 7, 2015

This seems to require a larger effort

The dashboard is not the only consumer of the API.

@kyungmin
Copy link

kyungmin commented Jan 7, 2015

@mjallday I thought #290 (comment) was specifically about allowing the seller to directly view the dashboard. What other cases are we trying to solve?

@sophistry
Copy link

We would like to be able to delegate evidence submission tasks (there is no API for dispute evidence submission so someone has to collect the merchant dispute evidence and submit it by typing and uploading files, etc...) so a privilege for access to disputes portal only would be very useful for us to be able to allow an intern to do that (for example).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants