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

Tasks #1

Open
CMCDragonkai opened this issue Jul 9, 2013 · 2 comments
Open

Tasks #1

CMCDragonkai opened this issue Jul 9, 2013 · 2 comments

Comments

@CMCDragonkai
Copy link
Member

No need for current URI
We have:

(these you just set at the start, you don't work on it anymore)

  1. Credentials object (initial setting)
  2. Storage object (initial setting)
  3. Service Object ($this->github)

From the service object, we'll use two methods to get two more objects:

(this is required, since certain storage interfaces may store the token object at this point, and it may not exist at the original object)
->getStorage() - Gets the storage object that we can use:

->retrieveAccessToken() - Gets the Access Token object so that we can then:

->getAccessToken() -> the actual access token code
->getRefreshToken() -> the actual refresh token code
->getEndOfLife() -> when the access token will expire

3 functions are necessary from the service object

  1. requestAccessToken() to be used when you are authorising
  2. request() to be used when wanting to do something
  3. refreshAccessToken($tokenObject) (trigger this when the token expired) (if it is -9001, that is unknown, we still need to trigger, if doesn't exist, throw an exception and need to redirect to do the thing again)

PROBLEM: how will we request user data to be filled? For example username/password? Perhaps we should leave this to the end developer and leave them blanks?

expires_in is a timestamp in the future. To check if it has expired: time() > expires_in

PROBLEM: Need a way of differentiating between oauth1 services and oauth2 services. Code inside could tell whether they are oauth1 or 2, or direct setting may be required. Auto detection will be good, also if the service does not exist, it will not be allowed.

PROBLEM: How to federate local accounts, multiple third party providers, and third party accounts.

SOLUTON: Use email as the id. We need to know what the email is of the user. This is dependent on the providers. Username cannot be the identifier... it is too conflictual. This is the only way we can federate the user accounts.

PROBLEM: Autologin does not understand external providers

SOLUTION: Autologin needs to check for all linked external accounts, and access them.

@CMCDragonkai
Copy link
Member Author

Consider offline access?

@CMCDragonkai
Copy link
Member Author

Encrypted Storage of Access/Refresh tokens. These are essentially passwords. But you cannot hash them, only encrypt them.

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

1 participant