Skip to content
This repository has been archived by the owner on Jul 21, 2022. It is now read-only.

oauth authentifizierung #4

Open
tabsl opened this issue Mar 14, 2012 · 6 comments
Open

oauth authentifizierung #4

tabsl opened this issue Mar 14, 2012 · 6 comments

Comments

@tabsl
Copy link
Member

tabsl commented Mar 14, 2012

ich würde folgende vorgehensweise vorschlagen, um sich per oauth zu authentifizieren.

  • zwei neue felder in oxuser: OXAUTH (tinyint) und OXAUTHKEY (varchar)
  • OXAUTHKEY = api-key
  • OXAUTH = user darf api nutzen: ja/nein

mit dem vorhandenen apikey kann ein user dann an die api andocken.
wird bei einem request ein gültiger api-key gefunden (OXAUTH true) darf der user sich am REST anmelden,
bekommt einen session-token, welcher eine definierte zeit gültig ist und kann loslegen.

fragen:
a) alle damit einverstanden?
b) wollen wir die vorgänge loggen? (anmeldeversuch, ip, etc?)
c) wie lang soll der token gültig sein?

Joscha to english
I think we should do it in the following way for oAuth:

  • Adding two new fields in oxuser: OXAUTH (tinyint) and OXAUTHKEY (varchar)
  • OXAUTHKEY = api-key
  • OXAUTH = user is able to use the api: yes/no

With the apikey the user could authentificate against the api. Is a valid key found, the session-token will be generated and set for a limited time.

questions:
a) anyone ack?
b) should we track these things (Loggins, IP,...)
c) how long should a token be valid?

@dennishei
Copy link

a) einverstanden + OXAUTHKEYCREATED um zu sehen wann er erstellt wurde
b) für 7 tage gerne, aber dann auch einen löschmechanismus integrieren....
c) 8 stunden halte ich für ein Minimum

@jkrug
Copy link

jkrug commented Mar 14, 2012

Sollen wir OXAUTH (tinyint) und OXAUTHKEY (varchar) oder AD2AUTH (tinyint) und AD2AUTHKEY (varchar) verwenden?

@jkrug
Copy link

jkrug commented Mar 14, 2012

b) +1
c) Können wir das in der admin2/config definieren?

@tabsl
Copy link
Member Author

tabsl commented Mar 14, 2012

OXAUTHKEYCREATED brauchen wir eigentlich nicht, wenn wir noch eine logtabelle haben wo man das auch reinschreiben könnte, oder?

@DSB
Copy link

DSB commented Mar 14, 2012

I wouldn't add that to the oxuser table but create a new table instead, which has the oxid of the user as the primary key. This way we could add more columns to the new table that are related to the rest mechanism (REST specific rights, configuration options, what do we need tomorrow?) without bothering about the row size of the oxuser table. We've had problems with the row size of the oxuser table if many modules have been installed and when many languages are present.
Additionally we are still independant from oxid updates and on the other hand won't limit oxid in the way the table oxuser can be used.

@tabsl
Copy link
Member Author

tabsl commented Mar 15, 2012

it sounds good, i´ll start now ...

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

No branches or pull requests

4 participants