all. I am currently working on a go project that requires me to connect to Google Analytics API v3. I am authenticating using service account method. I am pretty sure that I am able to authenticate but I am getting "insufficient_scope" error. I am not sure what's going on here.
My config struct
config := &jwt.Config{
Email:settings.Client_email,
PrivateKey:[]byte(settings.Private_key),
Scopes: []string{
"https://www.googleapis.com/auth/analytics.readonly",
},
TokenURL: google.JWTTokenURL,
}
The response header
Cache-Control:[private, max-age=0]
X-Xss-Protection:[1; mode=block]
Alt-Svc:[quic=":443"; p="1"; ma=604800]
Date:[Fri, 23 Oct 2015 17:45:13 GMT]
X-Content-Type-Options:[nosniff]
X-Frame-Options:[SAMEORIGIN]
Server:[GSE]
Alternate-Protocol:[443:quic,p=1]
Vary:[Origin X-Origin]
Content-Type:[application/json; charset=UTF-8]
Www-Authenticate:[
Bearer realm="https://accounts.google.com/",
error=insufficient_scope,
scope="https://www.googleapis.com/auth/analytics"
]
Expires:[Fri, 23 Oct 2015 17:45:13 GMT]
Figured it out. I just needed to add client email to Google Analytics account.
https://support.google.com/analytics/answer/1009702?hl=en#Add
Related
We followed this guide: https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/migration-faq#what-permissions-do-i-have-access-to
All developer applications created on the LinkedIn Developer Portal
after January 14, 2019 have access to the LinkedIn v2 API by default.
Alternatively, if your developer application has made a successful
LinkedIn v1 API request from September 1, 2018 to December 17, 2018,
your developer application has immediate access to the v2 API.
We also meet the criteria here regarding successful API requests between that time period.
We made the switch shortly before the holidays(as soon as they sent the announcement) and since the last week, we've started seeing this for new signups:
unauthorized_scope_error | Scope "r_liteprofile" is not authorized for your application
Should we revert back to r_basicprofile for now?
This is for "Sign in with Linkedin".
This is the GET request: https://www.linkedin.com/oauth/v2/authorization?client_id=XXXX&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fauth%2Flinkedin%2Fcallback&response_type=code&scope=r_liteprofile+r_emailaddress&state=XXXX
This is the response redirect: http://localhost:3000/auth/linkedin/callback?error=unauthorized_scope_error&error_description=Scope+%26quot%3Br_liteprofile%26quot%3B+is+not+authorized+for+your+application&state=XXXX
Thanks!
I was running into this today, and the step I was missing was I needed to add the "Sign In with LinkedIn" product to my app.
The terminology here is quite strange, but the screenshots help. You need to visit the "products" page on the developer portal (url like: https://www.linkedin.com/developers/apps/[your app id]/products)
After you do this and your request is approved (took <5 min for me) then the "OAuth 2.0 scopes" listed under the "Auth" tab will be expanded to include "r_emailaddress" and "r_liteprofile".
Has anything changed with regard to refreshing Google tokens using the MobileServiceClient against App Service. I used to be able to refresh Google tokens in my Xamarin Forms app using the MobileServiceClient. Now, after logging in, any attempt to refresh returns forbidden.
My login code is as follows:
public class Authentication : IAuthentication
{
public async Task<MobileServiceUser> LoginAsync(MobileServiceClient mobileClient, MobileServiceAuthenticationProvider provider)
{
return await mobileClient.LoginAsync(
Forms.Context,
provider,
new Dictionary<string, string>()
{
{ "access_type", "offline" }
});
}
}
My refresh code is:
var user = await MobileService.RefreshUserAsync();
The refresh fails even if I try refreshing immediately after my successful login. The Token Store is configured "On". The refresh works fine against the Microsoft provider. It was working a few months ago.
Microsoft.Azure.Mobile.Client v3.1.0
Microsoft.Azure.Mobile.Server v2.0.0
Browsing directly to https://[my-website].azurewebsites.net/.auth/login/google returns "You have successfully signed in"
Browsing directly to https://[my-website].azurewebsites.net/.auth/me returns [{"access_token":"ya29.Gl3ZAw6B1H0cT_e6vRlHgwQd0U-bcDSKo_CGQ9wKwPH8H-EbtNojP61JSzDaiIgSzU14PrT3QRb14NsFPhFYrU8ikCPGkhwKkZMAtHCNSdzDhTPm5cl89VrAlNc3vRU","expires_on":"2017-01-20T15:00:21.3928445Z","id_token":"eyJhbGciOiJSUzI1NiIsImtpZCI6IjZlYzMwOTBlZjgyM2YxMWFhN2VhNDE0N2FlZWM1Zjk0YmViNWZkMDMifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJpYXQiOjE0ODQ5MjA4MjEsImV4cCI6MTQ4NDkyNDQyMSwiYXRfaGFzaCI6IlhHa3dqOFpiZU9GX2N3SmpqeEpMRnciLCJhdWQiOiI3NDgwNzM0Njg2NDktanRtNTl0N21sY3NjaTg5bG9rYnV2c2VvYW5uMjhiZ3EuYXBwcy5nb29nbGV1c2VyY29udGVudC5jb20iLCJzdWIiOiIxMDE4MTI5MTIzODE5MTgwNDA4NDciLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYXpwIjoiNzQ4MDczNDY4NjQ5LWp0bTU5dDdtbGNzY2k4OWxva2J1dnNlb2FubjI4YmdxLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwiZW1haWwiOiJnY3JvY2tlbmJlcmdAZ21haWwuY29tIiwibmFtZSI6ImdlcmFyZCBjcm9ja2VuYmVyZyIsInBpY3R1cmUiOiJodHRwczovL2xoNS5nb29nbGV1c2VyY29udGVudC5jb20vLVpINUxBQ1RhQTRJL0FBQUFBQUFBQUFJL0FBQUFBQUFBQUFBL0FLQl9VOHRpamZ5ZUN3Qk9tWUxzTmM4QUZJcTNDVGJhVHcvczk2LWMvcGhvdG8uanBnIiwiZ2l2ZW5fbmFtZSI6ImdlcmFyZCIsImZhbWlseV9uYW1lIjoiY3JvY2tlbmJlcmcifQ.Qie3hRwKP-mbzMp3gzWatmQdLLVw3Ae7PXw1Ly8Se7-EQWBPgky0TsQ-fvZIasiHaq1tQu9lXyNu9qYqaaAvKxKCGxRE5yYhC76Yar_rQig14lf42bMRYQ3ADzwsPZ0yUbEpk-h4_HU5Ld1lNqYG-hgzEdUsJm_uspJk7FggwcfuPw-YQJr-GXbqd2Om9fmgGPrPrsFy7EzPGL27q_BIY3cOLEVX0e3tbAAVhxFCri835nBKdkYOP9X2g6wSuMWCq6iPOjFzErhVYR_WUwi5H-UW6mJHswcAfs_3Hwwt9RzCqfcyS1ZaehQVJE5B3uvK9WmAOrbD7uyEQmSli_zRWw","provider_name":"google","user_claims":[{"typ":"iss","val":"https://accounts.google.com"},{"typ":"iat","val":"1484920821"},{"typ":"exp","val":"1484924421"},{"typ":"at_hash","val":"XGkwj8ZbeOF_cwJjjxJLFw"},{"typ":"aud","val":"748073468649-jtm59t7mlcsci89lokbuvseoann28bgq.apps.googleusercontent.com"},{"typ":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier","val":"101812912381918040847"},{"typ":"email_verified","val":"true"},{"typ":"azp","val":"748073468649-jtm59t7mlcsci89lokbuvseoann28bgq.apps.googleusercontent.com"},{"typ":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress","val":"[my-googleemail]"},{"typ":"name","val":"[my - name]"},{"typ":"picture","val":"https://lh5.googleusercontent.com/-ZH5LACTaA4I/AAAAAAAAAAI/AAAAAAAAAAA/AKB_U8tijfyeCwBOmYLsNc8AFIq3CTbaTw/s96-c/photo.jpg"},{"typ":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname","val":"[my-givenname]"},{"typ":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname","val":"[my-surname]"}],"user_id":"[my-googleemail]"}]
Browsing directly to https://[my-website].azurewebsites/.auth/refresh returns "You do not have permission to view this directory or page"
If I repeat those steps with "microsoftaccount" the last refresh step works.
From Azure request tracking:
107. -GENERAL_FLUSH_RESPONSE_START
0 ms
Informational
108. -GENERAL_RESPONSE_HEADERS
Headers
Content-Type: text/html
Server: Microsoft-IIS/8.0
X-FE-DATA: AppId:Unknown-StatusCode
X-Powered-By: ASP.NET
DWAS-Handler-Name: BEGIN|403|80|0x0|CONFIG_SUCCESS|ExtensionlessUrlHandler-Integrated-4.0|###.##.##.###|\###.##.##.##\volume-4-default\&ApiApp=0
0 ms
Verbose
109. -GENERAL_RESPONSE_ENTITY_BUFFER
Buffer
You do not have permission to view this directory or page.
0 ms
Informational
110. -GENERAL_FLUSH_RESPONSE_END
BytesSent 400
ErrorCode The operation completed successfully.
(0x0)
Turns out that, with Google logins, refresh tokens are only issued upon the first login. I moved my Azure website and repointed the OAuth client settings so I was able to login but the Token Store no longer had a copy of the refresh_token sent with my initial Google login. Found the rest of the answer here.
Not receiving Google OAuth refresh token
According to your detailed information, I noticed that when you browsing directly to https://[my-website].azurewebsites.net/.auth/me, the response did not contain refresh_token. To isolate this issue, you could refer the following steps:
1.Browser https://brucechen-mobile.azurewebsites.net/.auth/login/google?access_type=offline and login with google account;
2.Access /.auth/me to retrieve my logged information as follows:
3.Browser /.auth/refresh to see whether you could get the response with 200 http status code.
Also, you could follow this official tutorial about refreshing user logins in App Service Mobile Apps to troubleshoot this issue. Additionally, you could leverage Fiddler to capture the detailed response when you invoke MobileService.RefreshUserAsync().
End device: EMC ECS,
Protocol: AWS S3
I'm trying to authenticate with my Python script and construct the same request using Paw.
Python with boto works just fine.
The primitive code:
from boto.s3.connection import S3Connection
accessKeyId = 'objuser'
secretKey = 'spl4vDHl11H7uW/683WZCoYrle03Bn1hd42gy8bd'
host = '10.10.10.10'
port = 9020
conn = S3Connection(aws_access_key_id=accessKeyId,
aws_secret_access_key=secretKey,
host=host,
port=port,
calling_format='boto.s3.connection.ProtocolIndependentOrdinaryCallingFormat',
is_secure=False)
print conn.get_all_buckets()
Correct headers are accepted by the S3 server
Date: Fri, 08 Apr 2016 07:38:34 GMT
Authorisation: AWS obtuser:Gi/qcdbyYcVMdI9EkdORPMx2wbo=
Next I re-create the same request with Paw but get wrong headers:
Date: Fri, 08 Apr 2016 07:38:34 GMT
Authorisation: AWS obtuser:/znFNFviqD5fw3t1oWUwBQ8B5M4=
Of course it is rejected by the S3 server.
In Paw I use Authorisation header with standard "S3 Amazon S3 Authorisation Header" dynamic value. AWS Access Key ID and Secret Access key ID are the same as in the script (triple checked).
According to the ECS documentation, S3 Authentication follows Signing and Authenticating REST Requests So signature is based on the standard HMAC-SHA1.
I expect that the same method is used by Paw.
Could you please advice what is potential reason why Paw doesn't create correct Authorisation header and how to fix that?
Many thanks in advance !
Sorry for the very late answer! I've just tested this again myself, using our AWS account, and for example, I've been able to list all our S3 buckets easily, see this screenshot:
It seems like it's probably an issue related to the way the Authorization header has been configured, or an invalid character being inserted in the URL field. (A screenshot would help to see what can be wrong)
Using Paw v3.0.16 and "Amazon S3 Authorisation Header" dynamic value, SignatureDoesNotMatch error occurred with this URL.
GET https://s3-ap-northeast-1.amazonaws.com/bucket123/sub456/some789.json
And it works well with this URL.
GET https://bucket123.s3.amazonaws.com/sub456/some789.json
http://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html
Description
In Web Api project template, after sending a POST request to the Token endpoint: www.mycoolwebsite.com/Token, we get a Json similar to this:
{
"access_token":"qkRwQD0A85...",
"token_type":"bearer",
"expires_in":14,
"userName":"admin#mycoolwebsite.com",
".issued":"Wed, 24 Feb 2016 18:15:53 GMT",
".expires":"Wed, 24 Feb 2016 18:16:08 GMT"
}
On the client side, (let say a mobile application) I am saving this json on a file, and to see if the token is expired, I compare DateTime.UtcNow to token's .expires key.
Question
Is this the correct way to see if an access token has expired?
If not, what is the best way check this?
I wouldn't check the access token's expiry time. Rather than build a mechanism to check the expiration time and handle it, why not just send the access token you have to the API and, if you get a 401 back, request a new access token. You'll have to build in logic to handle 401's anyway...why not rely on that instead?
My app with google calendar show this error:
The server had a problem handling your request.
com.google.gdata.util.ServiceForbiddenException: Forbidden
Forbidden<
Error 403
The problem it is in this code:
CalendarFeed resultFeed = service.getFeed(feedUrl, CalendarFeed.class);
Why does this happen?
This should answer your question:
https://developers.google.com/google-apps/calendar/v2/developers_guide_protocol
This API is a subject to the Deprecation Policy and will be shutdown on November 17, 2014. Please use APIv3 instead.