<FromGitter>
<andrewc910> @Blacksmoke16 okay i like your idea. I have been refactoring contrive & playing with the idea of returning a provider specific user object. It's really nice. Having a couple initialization methods in my internal user is a really neat trick. Thank you :)
<FromGitter>
<Blacksmoke16> 👍 np, glad its working well
<FromGitter>
<Blacksmoke16> following that PHP libs API at all?
<FromGitter>
<andrewc910> Haven't gotten that far. Started converting the provider users first. I figured i would get all the providers working in the new system and then go back on our conversation and add some of the more nifty features
<FromGitter>
<Blacksmoke16> 👍 sounds like a plan
<FromGitter>
<andrewc910> Right now i have a user class with a few abstract methods. I am making the provider user classes now. They inherit from this user, all have the same method names (ie: description) and i have to make the implmentation specific for that provider. Once all the providers have their own user class, i wanted to dig into that php you sent before :)
<FromGitter>
<Blacksmoke16> the main thing i was thinking is the like `resource_owner` method you could add to each provider implementation, which would return the specific user class for that provider
<FromGitter>
<andrewc910> `fake_user = Contrive::OmniAuth::Provider.user(params[:provider], {"code" => params[:code]}, url)` ⏎ ⏎ this is what needs to be in a controller for if you use contrive omniauth module. The method we are invoking returns a provider specific user object. `fake_user` will be the a GhUser or a FbUser for example.
<FromGitter>
<andrewc910> Is that what you're talking about? Maybe i am getting a little confused
<FromGitter>
<Blacksmoke16> under the hood its prob similar, i was still thinking of a more decoupled approach
<FromGitter>
<Blacksmoke16> but going along with @damianham's suggestion, it might be better to make these modeled in like an "integrations" table?
<FromGitter>
<andrewc910> hmm, well when i finish this round of implementation, may i ask for a quick code review and get tips to decouple it? We might of talked about it and i need to reread our convo. Just learning so much it's hard to digest everything at once.
<FromGitter>
<Blacksmoke16> i guess it depends on is this for like SSO into an application using one of these providers, or to allow an existing user to access APIs for that integration
<FromGitter>
<andrewc910> SSO
<FromGitter>
<Blacksmoke16> gotcha
<FromGitter>
<andrewc910> And in regards to @damianham I really like that idea as well. I just can't get behind it because in the Provider class we hardcoding `belongs_to :user`. If i could somehow make that more flexible, that would cool. And the other reason is i can't think of a reason why a single user needs multiple providers for login on a single service. Do users really need the ability to login with facebook OR google for the same
<FromGitter>
... account? ⏎ ⏎ I guess it boils down to benefits of said implement vs the current. I am open for discussion when we are both free!
<FromGitter>
<Blacksmoke16> if the goal of this is to login to an application via a third party account, then it should probably provision a user based on the info from their id token or whatever
<FromGitter>
<Blacksmoke16> never really did an implementation of something like that so not sure of the details
<FromGitter>
<Blacksmoke16> like should you store their token and stuff as well, etc
<FromGitter>
<andrewc910> Yeah, that is all available in the user object i return. It also contains the raw json returned by the provider in case you really need it.
<FromGitter>
<Blacksmoke16> nice nice
<FromGitter>
<damianham> @eliasjpr the amberframework/recipes repo is out of date and no longer used. Recipes are created in github user accounts such as damianham/amber_material_kit and tagged with 'amber-recipe' so they show up in a search when you go to https://github.com/topics/amber-recipe. Thanks for the compliment, much appreciated. One of the problems of recipes is that they soon become out of date given crystal, amber and the
<FromGitter>
... shards we use are updated on a fairly frequent basis. I have the time to keep my amber apps up to date but less so to keep my recipes up to date.
<FromGitter>
<damianham> @Blacksmoke16 I am sure @andrewc910's implementation is primarily for SSO using one of the providers. However some apps will also want access to a provider's API. It might seem like a good idea to implement Oauth from a provider in a shard that also has API access features but I don't think it is. Better to stick with SRP and have authentication in it's own shard and API access in another shard.
<FromGitter>
<Blacksmoke16> 👍 works for me
<FromGitter>
<damianham> @andrewc910 I was basing my suggestion primarily on my experience of building a website where you could login with any of the supported Oauth providers (Twitter,FB, Google, Github, LinkedIn). As a user - when you come back to the website at some later date can you remember which provider you logged in with ? I have accounts with all of those providers so which one did I use 2 months ago to login to
<FromGitter>
<damianham> I agree that hardcoding ```belongs_to :user``` in the Provider class is not totally optimal but in 30 years as a software engineer/architect every user table on every project I have ever worked on has been called - 'users'. I appreciate that the Amber Auth generator does allow you to specify a different class name - hands up anyone on this list who has used a different class name as the primary user identity class.
<FromGitter>
... So while allowing the belongs_to class association to be flexible it might be a case of YAGNI. Sorry for all the acronyms today chaps :)
<FromGitter>
<damianham> Alternatively is there a way you can specify the Provider class in a config setting or initializer so a developer can create an alternative Provider class with a different relationship class name? It would have to be very skinny of course so any methods would have to be included from a module.
<FromGitter>
<Blacksmoke16> > Of course I can't remember so I click on one of them and I now have a new User ID on www.myuselesswebsite.com and lost all my previous data. ⏎ ⏎ It would be assumed that both your SSO accounts share the same email id imagine?
<FromGitter>
<Blacksmoke16> that would be the only real unique id that could be shared between all three systems
_whitelogger has joined #amber
feepbot has quit [Ping timeout: 258 seconds]
feepbot has joined #amber
<FromGitter>
<damianham> Not neccessarily. IIRC when the user logs in via an Oauth provider the callback gets some provider specific data which may or may not include an email, but IIRC you can ask for more data in the API call and the user is informed about which data will be shared with your website and the user can choose to share or not share certain elements. The callback then finds the local user record for the provider data and
<FromGitter>
... that is the current_user for the session. The identity of the user i.e. the full name for display purposes is given by the provider data. So in a scenario where I login initially via Twitter if I agree to share all my twitter profile details you have access to my twitter handle, display name and email address associa ... [https://gitter.im/amberframework/amber?at=5e2451f5ad195a0f6735a547]
<FromGitter>
<Blacksmoke16> But how would you know that a record in the database is the same person without some common piece of data that is shared between them?