Possibilité de créer son propre agenda

[EmmanuelDemey]

Pouvoir selectionner les conférences qui nous intéressent , et de les retrouver dans une page spécifique.
Utilisation de Firebase ?
Comment persister à travers les devices ? Via une auth Oauth ?

[fgruchala]

De souvenir, @lborie m'avait parlé d'un compte GCP avec un quota gratuit pour certaines technos. Si c'est tjrs le cas, on partirait sur du back Go + Firebase ?

Et une authentification en oauth2 avec comme fédérateur d'identité Google, Twitter, Github ? Pour cette partie, j'ai une solution : KeyCloak (http://www.keycloak.org/) qui se charge de tous les aspects : connexion, fédération, utilisateur, etc. mais ça tourne sur du wildfire (java) ...

[lborie]

Autant go, tu peux faire tourner sur appengine en quota gratuit, autant faire tourner un wildfly, on va devoir payer, et je ne trouve pas que la plus value en vaille la peine...

[fgruchala]

Quelqu'un a donc une solution pour implémenter la fédération d'identité tierce ?

Si je résume pour être sûr d'avoir compris. Nous voulons proposer une authentification au travers des serveurs d'autorisations Google ou Twitter ou Github ou etc. afin de persister l'agenda.

Pour ce faire, nous devons, selon moi, avoir notre propre SSO qui va créer localement un compte utilisateur et l'associer à son compte Google ou Twitter ou Github ou etc. (la fédération d'identité).
Notre SSO sécurisera, à termes, notre front et notre back au travers d'un échange de token.

C'est bien cela ?

[lborie]

Firebase fait ça nativement il me semble...
https://firebase.google.com/docs/auth/

[fgruchala]

En voilà un début de réponse, merci :) Le mer. 25 oct. 2017 à 13:00, Ludovic Borie <notifications@github.com> a écrit :

Firebase fait ça nativement il me semble... https://firebase.google.com/docs/auth/ — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALobcaU-92lVzASQOBnTamt0yz9GXGqgks5svxTZgaJpZM4QBhjy> .

-- François GRUCHALA <linkedin>francoisgruchala</linkedin> <twitter>@fgruchala</twitter> <tel>+33 (0)677264684</tel>

[fgruchala]

Cela dit, je réitère, avoir notre propre SSO nous permettrait d'avoir notre propre BDD utilisateur (idéal pour nos campagnes/relances mail, etc.)

Pour ma curiosité et pcq je ne connais pas le fonctionnement de GCP (et j'aimerai), ça couterait combien ?

[lborie]

Il faudrait qu'on en discute de vive voix, mais ce n'est pas parce que tu fais du SSO grâce à un service tiers que tu n'as pas ta propre base utilisateur. Le SSO te sert juste à t'éviter d'avoir à stocker un login / mdp. Par contre, le callback du SSO va te fournir nom, prénom, mail, et tout ce qui t'intéresse sur l'utilisateur...

Et je pense qu'à notre échelle, l'utilisation de firebase couterait genre... rien.

[EmmanuelDemey]

Hello

Alors je comprends bien tes problématiques François. Voilà ce que j'ai en tête, n'hésite pas à me contretir Ludo et toi. Je n'ai pas testé la solution :D et je ne suis pas un expert de OAuth

1. Côté front faire une connexion via firebase auth . Par exemple ici avec twitter : https://firebase.google.com/docs/auth/web/twitter-login

A partir du retour de la requête, tu vas recevoir le token, mais également les informations de l'utilisateur. Attention, cet objet doit être différent en fonction du provider (Google vs Github vs Twitter)

firebase.auth().getRedirectResult().then(function(result) {
  if (result.credential) {
    // This gives you a the Twitter OAuth 1.0 Access Token and Secret.
    // You can use these server side with your app's credentials to access the Twitter API.
    var token = result.credential.accessToken;
    var secret = result.credential.secret;
    // ...
  }
  // The signed-in user info.
  var user = result.user;
}).catch(function(error) {

});

Cet utilisateur rien de t'empeche de l'envoyer au back GO (si vous choisissez GO) afin de le persister dans une base firebase ?

A partir de cet utilisateur persisté, nous pourrons lui ajouter les conférences qu'il a choisi. Pour chaque requête envoyée, faudra passer le token au back pour pouvoir persister l'agenda au bon utilisateur.

[fgruchala]

Oui oui, bien d'accord avec vous, je ne savais pas que firebase gérait l'oAuth et la fédération d'identité tierce. Je vais me pencher sur le bousin. À+, Le mer. 25 oct. 2017 à 17:50, Emmanuel DEMEY <notifications@github.com> a écrit :

Hello Alors je comprends bien tes problématiques François. Voilà ce que j'ai en tête, n'hésite pas à me contretir Ludo et toi. Je n'ai pas testé la solution :D et je ne suis pas un expert de OAuth 1. Côté front faire une connexion via firebase auth . Par exemple ici avec twitter : https://firebase.google.com/docs/auth/web/twitter-login A partir du retour de la requête, tu vas recevoir le token, mais également les informations de l'utilisateur. Attention, cet objet doit être différent en fonction du provider (Google vs Github vs Twitter) firebase.auth().getRedirectResult().then(function(result) { if (result.credential) { // This gives you a the Twitter OAuth 1.0 Access Token and Secret. // You can use these server side with your app's credentials to access the Twitter API. var token = result.credential.accessToken; var secret = result.credential.secret; // ... } // The signed-in user info. var user = result.user; }).catch(function(error) { }); Cet utilisateur rien de t'empeche de l'envoyer au back GO (si vous choisissez GO) afin de le persister dans une base firebase ? A partir de cet utilisateur persisté, nous pourrons lui ajouter les conférences qu'il a choisi. Pour chaque requête envoyée, faudra passer le token au back pour pouvoir persister l'agenda au bon utilisateur. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALobcVhfhnXV2XVnaZ_TwVh4WEwOG98wks5sv1i2gaJpZM4QBhjy> .

-- François GRUCHALA <linkedin>francoisgruchala</linkedin> <twitter>@fgruchala</twitter> <tel>+33 (0)677264684</tel>