I want to implement the login with WeChat. While reading the documentation, I came across two different parameters whose meaning I don't fully understand: openId and unionId.
Could someone explain what these id's really are? As far as I understood it should be like this:
openId - some unique id of the user that could change from time to time
unionId - the unique id of the user, the only one that is always the same. Equivalent to the unique id the Google returns when logging in using Google API.
The documentation I read can be found here: http://open.wechat.com/cgi-bin/newreadtemplate?t=overseas_open/docs/web/login/getting-user-profile#login_getting-user-profile
From my understanding, a user's open ids vary from web apps to apps, whereas union id stays the same. For example, you have two apps that use wechat login: W1 and W2. A user will have openid1 for W1 and oepnid2 for W2 seperately, but you can use the user's union id the uniquely identify him/her across the apps.
Open id only changes when you have more than one web/mobile apps.
Hope it helps. Thanks.
"why would anyone want to use an openID" - that is a very good question from #dcsan.
从api来讲的话，最大区别就是 unionId 需要 openId 和 access_token 去取得，也就是多了一个auth step。
从实用角度来看，openId更多起了一种 data anonymization 的作用。
除此之外 from what I understand,
openId = f(unionId, appId) where f是一个hash function，etc。
Update, it's probably something more like=
openid = f(userId, appId)
unionid = f(userId, appOwnerId)
where f是一个hash function
When your company have more than one official account, one same user follow both of them, the open id for one user are different. To solve this issue, wechat develop the union id to help identify different openid but same user.
Related
I was reading the Firebase Auth docs and in the "Manage Users" section I found this:
var multiFactorString = "MultiFactor: "
for info in user.multiFactor.enrolledFactors {
multiFactorString += info.displayName ?? "[DispayName]"
multiFactorString += " "
}
// ...
I wanted to know what this multifactorString means, or generally, what MultiFactor means in context to FirebaseAuth. Is it used to check what all providers a user can log in with (such as Google or Apple)? Or is it used for something completely different?
Please let me know what MultiFactor means, how I can make use of a MulitFactor object, and if my assumption was correct.
Thanks in advance!
GCIP (Google Cloud Identity Platform) is the upgraded version of Firebase Auth for Google Cloud developers. It also supports multi-factor authentication using SMS as a second factor. Basically after you sign in with email/password, or a social provider like Google or Facebook, you can still require an additional SMS challenge (this is independent on whether the user is using 2FA with Google)
The documentation for using this in iOS is available here.
The documentation you are referring to is the Admin SDK for managing enrolled second factors on a user. With this feature, you are able to enroll multiple second factors on the same user and you can assign them user friendly names for the user to choose from after completing the first challenge. This is documented here.
I'm trying to use the Google Calendar API in one of my projects. To do so, I need to set up OAuth access in the Google API console.
But when creating the consent-form (which is required to use OAuth), I get a meaningless error message:
The translation is as follows:
A problem occured. Please check your data and try again . If you have
not given any details, the problem may solve itself . In this case, we
recommend that you wait and try again later.
I have set the E-Mail address and project name. The optional fields were left blank.
So far I have not been able to solve the problem. I tried to wait for hours/days. I tried three different browsers. I also tried to contact Google support. All without success.
After days of trying, this is the solution:
Create another Google account
Using your old account, add the new account as an owner to your Google API project in the console
Log in with your new user account and accept the invitation
Create the OAuth consent form with the new user account
I have no idea WHY this worked, but it did.
** UPDATE **
It truly seems that Google has just screwed every single person on the planet by absolutely requiring user interaction to upload a video. Of course I know, they are free. Exactly what I warned the client years ago about, so I don't need to be reminded. Thank You.
So I would like to try to take this in a different direction and just find a loophole and a workaround to still keep doing what we are doing in spite of Google's complete lack of support or caring in any way about the developers and what they have to deal with.
It would be different if you can actually call a phone number and talk to a human being about YouTube Partner access, but you can more quickly get access to the Illuminati.
OAuth 2.0 is now the only supported authentication method period. It does require user interaction.
But what about that token? Does anybody know how long the token lasts?
If I can obtain a token just once using user interaction and place it in the database, I can automate possibly hundreds or thousands of interactions afterwards.
In other words, I'm trying to turn the user interaction into a speed bump instead of a concrete wall.
If anybody has any examples of obtaining that token, caching it, and using it afterwards, that would be a godsend to me right now.
Thanks for the comments and the help. I'm not surprised that the YouTube Developers Forum just folded and said to come here instead :)
It seems that Google has completely pulled the plug on the existing dashboard.
https://code.google.com/apis/youtube/dashboard/gwt/index.html
That link is now 404'd. Tried from several different browsers on different systems.
Registered under the new Google APIs Console already, but still get the problem.
// Set the authentication URL for this connection object
$authenticationURL= 'https://www.google.com/youtube/accounts/ClientLogin';
// Try to connect to YouTube with the channel credentials passed
try {
$httpClient =
Zend_Gdata_ClientLogin::getHttpClient(
$username = $channelfields['EMAIL_ADDRESS'],
$password = $channelfields['PASSCODE'],
$service = 'youtube',
$client = null,
$source = 'Redacted Data',
$loginToken = $channelfields['CACHED_TOKEN'],
$loginCaptcha = '',
$authenticationURL);
} catch (Zend_Gdata_App_HttpException $httpException) {
$update_error['response_body'] = $httpException->getRawResponseBody();
$update_error['error'] = 1;
} catch (Zend_Gdata_App_Exception $e) {
$update_error['message'] = $e->getMessage();
$update_error['error'] = 1;
}
This code has worked perfectly fine before, but does not work with the older API key, or the newer one generated inside the Google APIs console.
I'm attempting a simple upload and this concerns me greatly:
"The service account flow supports server-to-server interactions that do not access user information. However, the YouTube Data API does not support this flow. Since there is no way to link a Service Account to a YouTube account, attempts to authorize requests with this flow will generate a NoLinkedYouTubeAccount error."
From all reports it seems that Google has forced YouTube uploads to become interactive in all cases precluding all possibility of platforms that automatically upload generated content from working at all.
Any help or insights into the process is appreciated.
P.S - Ohhh, it's been awhile since I looked at that system and Google shut down the YouTube Developer Forums and said "YOU" were responsible for their support now :)
OAuth2 does support the ability to avoid user interaction through the offline access type parameter (ie, using access_type=offline). Check out Google documentation for details.
The solution is really rather simple. Your app needs to use oauth to request offline access. It will be given an access cide which you convert to a refresh token, which is the thing you store in your database. This doesn't expire. Well actually it sometimes does, but that's another story. Whenever you need to access the api, use the stored refresh token to request an access token which you include in each api call.
See https://developers.google.com/accounts/docs/OAuth2WebServer for details.
I don't know what you did but https://code.google.com/apis/youtube/dashboard/gwt/index.html works perfectly fine for me. Maybe it was a temporary issue. If you want no user interaction you HAVE to use YouTube API v2 OR you have to use v3 with methods that don't require authentification OR you have to provide your own youtube account credentials which is not recommended and probably not appropriate for you situation.
Several issues to respond here, I think.
1) The older API console has not been removed, but I've noticed intermittent outages to it and to the newer API console while Google is rolling out their new "cloud console."
2) ClientLogin was officially deprecated in April of 2012, not just 48 hours ago. Jeff Posnick has detailed all the changes over the months (and related ones, such as AuthSub, Youtube Direct, etc.) at his blog (apiblog.youtube.com).
3) You're right that, with v3 of the APIs, you cannot do automatic uploads across the board, as the oAuth2 flow requires user interaction. However, given the limited description of your use case, using refresh tokens is probably your best bet. If the content is user generated, somewhere they must be logging into your app, correct? (so that your app knows which credentials to leverage to do the uploads). At the point they're logging into your app, and you're starting the oAuth2 flow, you just have to hit the first oAuth endpoint and pass it the parameter access_type=offline (along with any other parameters). This will ensure that, when they grant that initial permission, you're returned a refresh token instead of an access token. With that refresh token, you can exchange it for multiple access tokens as needed (an access token lives for about an hour. I don't know how long a refresh token lives, but I've never had one expire before my own login cookies did, and then I just get a new one when my users re-login to my app).
Here's some more info on how to use the refresh token; note, too, that the various google api client libraries make it pretty smooth.
https://developers.google.com/accounts/docs/OAuth2WebServer#refresh
Also, this video tutorial from a Google Developers Live broadcast a couple of months ago might help illustrate the point: http://www.youtube.com/watch?v=hfWe1gPCnzc -- it's using the oAuth playground rather than a client library, but the concept is the same.
The answer is to use google-api-php-client, create an interactive auth page, and set up YouTube API v3 correctly with the new API console.
You can create a very simple page that will authenticate for the supplied channel and then store the correct token in your database. Is already working and uploading hundreds of videos on one channel. You do need to remember to fully activate yourself under the new API console and add the services required. Just keep authenticating and adding the services it says it needs. After that, the regular v3 upload process works just fine. On failure send a group an email and they can get a new token in 10 seconds.
Not the most elegant solution, but the documentation from Google is far from elegant anyways that Stack Overflow is now their front line support.
Just hang in there, a solution is always found. Don't give up!
I didn't get here by myself either, the other answers on this page helped me get all the way to this point. Thanks guys.
P.S - Don't forget the scopes
$client->setScopes("https://www.googleapis.com/auth/youtube https://www.googleapis.com/auth/youtube.upload");
I'm quite familiar with OAuth 2 for other providers, but haven't used it for Instagram before.
Like many developers, I have multiple domains where my app may run, eg:
http://www.foo.com/oauth2callback
https://www.foo.com/oauth2callback
http://localhost:3000/oauth2callback
https://localhost:3000/oauth2callback
Other OAuth 2 providers I have used, eg, Google, allow multiple entries in a redirect_uris parameter.
However Instagram only seems to allow a single Redirect URI parameter per registered app.
Can I have multiple redirect URIs for a single Instagram app or do I have to register multiple apps, each with a different redirect URI?
With Instagram apps that I have created, I have created a separate app per place I want to redirect to, although I haven't discriminated by ssl. I then load the api credentials into the app based on the environment it is running in.
It is a pain that you have to do that, as Instagram also restrict you to 5 registered apps per account too. It would be useful to be able register multiple redirects for that reason. But on the other hand, it would be just as good, for me, to not be restricted to the number of apps you can create (I've got more Twitter apps than I even remember creating!).
It looks like now you can set multiple Redirect URL(s) when you register/edit a Client in Instagram:
I think this is one of those scenarios that you feel back in the Atari.
anyway, I found useful doing this one:
edit your hosts file (in unix based OS: /etc/hosts)
make sure you add a line like this:
127.0.0.1 registeredomain.com
Where registeredomain.com is the domain you have in instagram as your production return uri.
In this way your app will return uri to registeredomain.com that is equivalent to localhost in your local machine, accepting the login.
btw: why? why? why? why instagram, why you have to force one return uri? any reason for that?
Due to every AppID seems need a correspond URL, that means, every our device needs to apply one AppID with its URL. This is not suitable and not OK for our device goes into mass production due to we don't know the url of the end user. So, does anyone know how to solve this issue?
*
Facebook doesn't allow to create appid now, am having below error.
*You can no longer create apps because our systems indicated that your account may not be authentic. Facebook requires users to provide their
real first and last names, and fake accounts are a violation of our
Statement of Rights and Responsibilities (SRR 4.1), even when used to
host or test apps. Also note that maintaining multiple accounts, even
if they are authentic, is also prohibited. If you would like to create
a test user to test app functionality, you can do so here:
http://developers.facebook.com/docs/test_users/.*
*