I'm using firebase.auth() for my Website. I activated the firebase.auth.Auth.Persistence.LOCAL option to stay logged in (which shouldn't be necessary, since its the default in web, according to https://firebase.google.com/docs/auth/web/auth-state-persistence, but it doesn't matter, if the option is explicitly set or not).
The expected behaviour is, that the user stays logged in, until he actively signs out, no matter if the browser was closed. etc...
In my case, the user is logged out after an hour or so (didn't tracked it exactly). This happens on safari, or if I add it to the homescreen as webapp. I this the intended behaviour, or am I doing something wrong?
Update: Problem solved
I totally missed a 403 answer in the console after a few couple of minute:
{
"error": {
"code": 403,
"message": "Token Service API has not been used in project xxxxxx before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/securetoken.googleapis.com/overview?project=xxxxxx then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
"status": "PERMISSION_DENIED",
"details": [
{
"#type": "type.googleapis.com/google.rpc.Help",
"links": [
{
"description": "Google developers console API activation",
"url": "https://console.developers.google.com/apis/api/securetoken.googleapis.com/overview?project=xxxxx"
}
]
}
]
}
}
I went to the url, activated the token api and voila: persistent Logins :)
Afterwards I looked up the official docs, seeing if I missed this step somewhere, but I can't find any hints on that api activation.
Related
I am completely new to building Zendesk apps so I have been working my way through the documentation:
https://developer.zendesk.com/documentation/apps/build-an-app/build-your-first-support-app/part-1-laying-the-groundwork/
My client side app runs inside the Zendesk ticket sidebar. It needs to pull data from an external api, so I am adding these values into the manifest.json (as outline in the docs):
"oauth": {
"client_id": "...",
"client_secret": "...",
"authorize_uri": "...",
"access_token_uri": "...",
"scope": "read write"
},
"parameters": [
{
"name": "access_token",
"type": "oauth"
}
]
However as soon as I add the oauth keys into the manifest, my local ZAT server crashes. So the server will startup correctly, but as soon as I refresh Zendesk in my browser the server will crash. The resulting Ruby crash report doesn't give much away (to me at least).
So I'm pretty much falling at the first hurdle here. Any pointers would be greatly appreciated. I will just mention that I'm on an M1 MacBook, just in case there are any incompatibilities with ZAT Server.
So I'm not sure the reason my ZAT server kept crashing, but the solution was to abandon it in favour of the new ZCLI server:
https://develop.zendesk.com/hc/en-us/articles/360050791614-Introducing-ZCLI-The-Zendesk-Command-Line-Interface-Beta
Currently our Youtube data API v3 is enabled.
However, we found there was some error while we calling this API.
The screen shows as the following:
Google_Service_Exception : {
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "accessNotConfigured",
"message": "Access Not Configured. YouTube Data API has not been used in project 10xxxxxxxxx29 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=10xxxxxxxxx29 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
"extendedHelp": "https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=10xxxxxxxxx29"
}
],
"code": 403,
"message": "Access Not Configured. YouTube Data API has not been used in project 10xxxxxxxxx29 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=10xxxxxxxxx29 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."
}
}
We try to create a new O Auth 2.0 ID, but the issue was still got same error.
Is there any way to resolve this problem?
Thanks
Google allows for 50000 request per month/per user.So seem your website has high traffic.You can get another API key from your other gmail then put into API settings.Hope this help.
I am getting a list of users in an organisation from the Jira ServiceDesk API, as documented on this page.
So far this is working as expected but today all off a sudden the code is broken. That is to say; the results im getting from the API have changed. As the docs state i SHOULD be getting values that include the field emailAddress. However since today i am getting the right users, but there is no longer an emailAddress field. The following is the result (structure) i'm recieving:
{
"size": 1,
"start": 0,
"limit": 50,
"isLastPage": true,
"_links": {
"self": "https://someprefix.atlassian.net/rest/servicedeskapi/organization/1/user?start=0&limit=50",
"base": "BaseURL",
"context": ""
},
"values": [
{
"accountId": "123456:SomeGUID",
"name": "SomeUserName",
"key": "someusername",
"displayName": "Some Username",
"active": true,
"timeZone": "Europe/Amsterdam",
"_links": {
"jiraRest": "LinkToTheThisUser",
"avatarUrls": {
"48x48": "LinkTo48X48Url",
"24x24": "LinkTo24X24Url",
"16x16": "LinkTo16X16Url",
"32x32": "LinkTo32X32Url"
},
"self": "LinkToThisResource"
}
}
]
}
I asked to check the setting User email visibility and it is currently set to logged in users only.
My question:
Why is this field suddenly missing from the API? Is there or are there settings i'm unaware off that influence this field being present or not?
Ok, it seems this is by design to keep in line with GDPR guidelines. Long story short; emailAddress will no longer be reliably part of the API's since a user now has to consent to it. If not all users emailAddresses are reliably part of the response this makes for a poor field of comparison in synchronization applications.
Which profile information will apps be able to access?
Any personal information users set as Anyone will be available for apps to use. For
example, apps will be able to access this information, store it, and
show it to other users.
Users' local times and locations will always be available to apps,
regardless of their visibility settings. This lets apps customize
their experiences.
Users' email addresses will be available to some apps that have been
approved by Atlassian. Note that if a user chooses to set their email
address to Anyone, then any installed apps will be able to use it.
When users install apps, the apps will request that they consent to
share their profile information with the apps. If they consent, the
apps will have access to all of their profile information. This is not
applicable to admins.
However. There will be a new API giving access to user emailAddresses regardless of user settings. Access to this API is restricted to approved applications. More about this can be found on this page.
In order to apply for access to this API the app must meet all current
requirements for being listed on Atlassian Marketplace (even if the
app is not listed on Atlassian Marketplace).
This means:
The app developer has provided a privacy policy
The app developer has provided a customer terms of use agreement
The app developer must signal whether or not the app collects and stores personal data.
If the app is storing personal data the app must report the accountIDs that have been collected and stored every 15 days.
We are using youtube-v3-api for quite some time now but suddenly it started responding with error 403 saying that the access needs to be enabled.
Here is the error message:
{
"code": 403,
"errors": [
{
"domain": "usageLimits",
"message": "Access Not Configured. YouTube Data API has not been used in project {projectId} before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project={projectId} then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
"reason": "accessNotConfigured",
"extendedHelp": "https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project={projectId}"
}
],
"message": "Access Not Configured. YouTube Data API has not been used in project {projectId} before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project={projectId} then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."
}
But the api is enabled and it worked for months:
We use the api with oauth2 tokens and with API keys as well but we receive the same error for both.
What can be the problem?
I tried to disable and reenable the API but that didn't help.
Update:
Google support suggested that the issue maybe caused by the daily quota limit which is set to 0.
However we cannot edit this quota as shown in the picture although we have all admin rights to do so.
Does anyone experienced this? How could we raise the quota?
We already filled out a quota limit extension form and waiting for the response but I think we should be able to set to quota to a workable level on the developer console.
I'm using gem omniauth-google-oauth2 to login with google from Rails app.
These days I'm getting this error:
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "accessNotConfigured",
"message": "Access Not Configured. Please use Google Developers Console to activate the API for your project."
}
],
"code": 403,
"message": "Access Not Configured. Please use Google Developers Console to activate the API for your project."
}
}
Same settings would work fine for localhost, but failed frequently and sometime work on production. I have no idea of what's going on? Is Google changing there API recently? What API do I need to enable just to login and get user info?
I came across this problem when updating from omniauth-google-oauth2 0.2.2 to 0.2.4. To resolve the issue, go to your Google Developers Console. Click on "APIs" and enable the "Contacts API" and "Google+ API". This GitHub issue describes the problem in more detail.
We're started experiencing the same issue 20 hours ago, but it's appearing on both production and localhost (which use two separate Google accounts). The strange thing is that we are able to log in every 3 or 4 tries, but not every time.
As far as an API change on Google's end, this issue on omniauth-google-oauth2 seems relevant: https://github.com/zquestz/omniauth-google-oauth2/issues/106. However, this deprecation should not be enforced until September, 2014.
Also, editing the omniauth-google-oauth2 gem directly and changing these lines:
class GoogleOauth2 < OmniAuth::Strategies::OAuth2
BASE_SCOPE_URL = "https://www.googleapis.com/auth/"
DEFAULT_SCOPE = "userinfo.email,userinfo.profile"
to this:
class GoogleOauth2 < OmniAuth::Strategies::OAuth2
BASE_SCOPE_URL = "https://www.googleapis.com/auth/"
DEFAULT_SCOPE = "email,profile"
Yielded this error:
Error: invalid_scope
Some requested scopes were invalid. {invalid=[https://www.googleapis.com/auth/profile, https://www.googleapis.com/auth/email]}
Update:
Quoted from an email from Lever (hire.lever.co):
"The issue stemmed from an bug in a release Google made to the authentication system Lever uses to identify users last night. We were among some apps who lost the ability to verify users via their Google OAuth API. We've been in communication with Google, and we've been told that the release was reverted at 11:30AM PDT."
Google OAuth appears to be fixed for us now.
We found that Billing had been enabled for one of our projects, but no Billing information entered. Disabling Billing for this particular project so far seems to have resolved this issue for us.
The error we were getting was:
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "accessNotConfigured",
"message": "Access Not Configured. Please use Google Developers Console to activate the API for your project."
}
],
"code": 403,
"message": "Access Not Configured. Please use Google Developers Console to activate the API for your project."
}
}
Update: Of course our fix was applied ~ 11:30 AM PDT, so I am I'm voting this was a Google issue.