Closed t1mmen closed 10 years ago
Good point @t1mmen
uid
and info.name
is set to required so that there can be a reliable method to ensure uniqueness of the user with respect to the provider; whereas info.name
so that there can be a reliable consistent way of getting display name.
I'm guessing for this case, depending on the cost and the complication, you can either:
access_token
as UID and/or display name.How you handle for your strategies will be up to you, but I would advise against the second method if access_token
changes or expires for the same user as consumer would not be able to reliable identify the specific user that way.
In my opinion when you need to query their api, you could just as well use their php library for this: http://campaignmonitor.github.io/createsend-php/
Opauth focuses on authenticating a user through oauth providers, not to get additional data from their apis.
You could ofcourse extend Opauth classes to make the authentication part work, but from there you still would probably use their library for querying their api anyway.
In Opauth 1.0 your strategy could return a custom Response class which extends the Opauth one, and override the isValid() method.
https://github.com/opauth/opauth/blob/1.0/src/Response.php#L106
"Query the provider to obtain the actual UID and/or display name, or" which uzyn mentioned does not seem possible as their api does not return user info in any way.
But your application will never be able to connect other data to the specific Campaign monitor user, as you have no identifier for this. For this reason by default Opauth requires uid/username
Hope this helps, if you feel we could make things easier for you, 1.0 is not yet feature frozen yet, so we could adjust the code if you have ideas.
2014-05-06 14:39 GMT+02:00 U-Zyn Chua notifications@github.com:
Good point @t1mmen https://github.com/t1mmen
uid and info.name is set to required so that there can be a reliable method to ensure uniqueness of the user with respect to the provider; whereas info.name so that there can be a reliable consistent way of getting display name.
I'm guessing for this case, depending on the cost and the complication, you can either:
- Query the provider to obtain the actual UID and/or display name, or
- Simply use access_token as UID and/or display name.
How you handle for your strategies will be up to you, but I would advise against the second method if access_token changes or expires for the same user as consumer would not be able to reliable identify the specific user that way.
— Reply to this email directly or view it on GitHubhttps://github.com/opauth/opauth/issues/91#issuecomment-42296814 .
Thanks for the insight!
I'll discuss it with the team and I'll let you know what we end up deciding on. My gut is telling me that OpAuth & CampaignMonitor just weren't meant to be, but I'm blaming the awkward CM API for that.
Also, thanks for all your hard work! Keep it up guys :)
I'm attempting a CampaignMonitor strategy, and I'm uncertain how to proceed.
Authentication works, but the response only contains (example)..
Technically, the
access_token
is all I really need to query the API, but I'm missing the requireduid
andinfo.name
.To get at this info, I need to query /clients.json, which might contain several clients - so which one do I pick? Should I just omit
uid
andinfo.name
?Any insight would be much appreciated!