Add Account Resource #39

New issue

Closed

opened 2025-05-14 15:10:51 +02:00 by rafael · 4 comments

rafael commented

2025-05-14 15:10:51 +02:00

Collaborator

For logging in.

rafael added this to the Accounts & Logins milestone 2025-05-14 15:10:51 +02:00

moritz added this to the Sprint 3 - 28.05 - 09.07 project 2025-05-28 16:52:20 +02:00

carla self-assigned this 2025-05-28 17:17:45 +02:00

carla added reference feature/36_add_primerlive

2025-05-28 17:20:34 +02:00

carla changed reference from ~~feature/36_add_primerlive~~ to feature/39_account_ressource

2025-05-28 17:20:37 +02:00

carla commented

2025-06-03 08:45:59 +02:00

Owner

Hi Zusammen,
ich wollte die Account ressource angelegen und bin dann ein bisschen abgedriftet und habe zum Thema Phoenix, Ash und Authentication AshAuthenticationPhoenix library gefunden. Damit habe ich jetzt ein wenig rumprobiert.
Hier der Link: https://hexdocs.pm/ash_authentication_phoenix/get-started.html
Hier die Notizen im Wiki: https://wiki.local-it.org/doc/ash-englisch-EO7IrlLlpK#h-authentication
Die Standard-Benamung der Ressourcen sind dabei User und Token in der Domain Accounts. Das weicht ein bisschen von unserer Benamung ab. Weiterhin habe ich es so verstanden, dass bei der Passwort Authentication Strategie unique identifier email oder username sein muss. Ich habe deswegen aktuell beim user die email jetzt doch auf mandatory gesetzt.
Was denkt ihr dazu?
Vorteil ist, dass AshAuthentication eben schon viel der Authentication übernimmt, login Seite bereitstellt etc. Mein Branch ist wie gesagt WIP aber ich habe nun mal AshAuthenticationPhoenix getestet. Die Route .../members könnt ihr jetzt nur eingeloggt erreichen.
@rafael @moritz @simon

Hi Zusammen, ich wollte die Account ressource angelegen und bin dann ein bisschen abgedriftet und habe zum Thema Phoenix, Ash und Authentication AshAuthenticationPhoenix library gefunden. Damit habe ich jetzt ein wenig rumprobiert. Hier der Link: https://hexdocs.pm/ash_authentication_phoenix/get-started.html Hier die Notizen im Wiki: https://wiki.local-it.org/doc/ash-englisch-EO7IrlLlpK#h-authentication Die Standard-Benamung der Ressourcen sind dabei User und Token in der Domain Accounts. Das weicht ein bisschen von unserer Benamung ab. Weiterhin habe ich es so verstanden, dass bei der Passwort Authentication Strategie unique identifier email oder username sein muss. Ich habe deswegen aktuell beim user die email jetzt doch auf mandatory gesetzt. Was denkt ihr dazu? Vorteil ist, dass AshAuthentication eben schon viel der Authentication übernimmt, login Seite bereitstellt etc. Mein Branch ist wie gesagt WIP aber ich habe nun mal AshAuthenticationPhoenix getestet. Die Route .../members könnt ihr jetzt nur eingeloggt erreichen. @rafael @moritz @simon

moritz commented

2025-06-03 10:17:52 +02:00

Owner

Wir können gerne die Stanadard-Benamung User/Token verwenden.
email auf mandatory zu setzen ist denke ich kein Problem, da auch per OIDC eine email übertragen wird. email sollte jedoch nicht als identifier verwendet werden, da User auch mal ihre email Adresse ändern können.

Wir können gerne die Stanadard-Benamung User/Token verwenden. email auf mandatory zu setzen ist denke ich kein Problem, da auch per OIDC eine email übertragen wird. email sollte jedoch nicht als identifier verwendet werden, da User auch mal ihre email Adresse ändern können.

👍 1

moritz commented

2025-06-03 10:27:06 +02:00

Owner

Erstelle gerne schon einen WIP PR dann können wir wenn du willst darin direkt Dinge kommentieren.
Habe den branch mal ausgecheckt und zum laufen gebracht, bekomme aber noch * ** (Postgrex.Error) ERROR 42P01 (undefined_table) relation "tokens" does not exist wenn ich einen user erstellen möchte.

Erstelle gerne schon einen WIP PR dann können wir wenn du willst darin direkt Dinge kommentieren. Habe den branch mal ausgecheckt und zum laufen gebracht, bekomme aber noch `* ** (Postgrex.Error) ERROR 42P01 (undefined_table) relation "tokens" does not exist` wenn ich einen user erstellen möchte.

👍 1

carla commented

2025-06-04 09:59:39 +02:00

Owner

Bezüglich: "Email sollte jedoch nicht als identifier verwendet werden, da User auch mal ihre email Adresse ändern können."
-> Auch wenn email als unique identifier für ddie AshAuthentication library angegeben ist, kann die Mail immer noch vom User geändert werden. So verstehe ich es zumindest. Hier ist zum Beispiel auch ein Tutorial wo der Anwendungsfall behandelt wird: https://hexdocs.pm/ash_authentication/confirmation.html

Bezüglich: "Email sollte jedoch nicht als identifier verwendet werden, da User auch mal ihre email Adresse ändern können." -> Auch wenn email als unique identifier für ddie AshAuthentication library angegeben ist, kann die Mail immer noch vom User geändert werden. So verstehe ich es zumindest. Hier ist zum Beispiel auch ein Tutorial wo der Anwendungsfall behandelt wird: https://hexdocs.pm/ash_authentication/confirmation.html

carla referenced this issue from a pull request that will close it,

2025-06-19 15:36:55 +02:00

Account Ressource # SSO closes #39, #40 and #41 #72

carla referenced this issue

2025-06-19 15:38:01 +02:00

Account Ressource # SSO closes #39, #40 and #41 #72

carla closed this issue

2025-07-02 17:05:56 +02:00

carla referenced this issue from a commit

2025-07-02 17:05:57 +02:00

Merge pull request 'Account Ressource # SSO closes #39, #40 and #41' (#72) from feature/39_account_ressource into main