The page that is handling authentication for Sony Lifelog seems to have issues that makes it inaccessible.
Neither of our applications (Both an Android app and a website) can get refresh-tokens nor access-tokens; the only response we get is ERR_EMPTY_RESPONSE.
Other people are experiencing it as well: https://talk.sonymobile.com/t5/Lifelog/Can-t-log-in-to-Lifelog/td-p/678295/page/2
API status dashboard says the service is up, though I suspect that it only refers to the actual Lifelog data API and not the authentication service.
Is this a known issue? And are there any work-around for now?
Related
I'm a backend developer, and I've developed a WebApi service with Asp.Net Core.
I've also developed ApiGateway using Ocelot library.
From front side, front-end developers use React and Axios as HTTP client.
When the request is provided to the API method directly, it works nice.
But when the request is called through the ApiGateway, response time is much bigger (more than 1-2 minutes).
This delay is performed from Chromium-based browsers f.e: Google Chrome, Microsoft Edge and Opera.
Everything is OK from Mozilla Firefox.
Also, there is no any problem from Postman and JMeter.
What can be a reason of a such behavior?
Or where should I try to find a solution, on the back or front side?
With API Gateway it requires going from the client to API Gateway,
which means leaving the application and going out to the internet,
then back to your application to go to your other Instance, then back
to API Gateway, which means leaving your application again and then
back to your first instance.
So this additional latency is expected. The only way to lower the
latency is to add in API Caching which is only going to be useful is
if the content you are requesting is going to be static and not
updating constantly. You will still see the longer latency when the
item is removed from cache and needs to be fetched from the System,
but it will lower most calls.
So I guess the latency is normal, which is unfortunate.
As for why it responds well on Mozilla Firefox, probably due to differences between API implementations.
The above is my point of view, I hope it will help you. If my understanding is wrong, please correct me, thanks.
I have an app engine service deployed in GAE (written in Node) to accept a series of click stream events from my website. The data is pushed as an CORS ajax call. I think, since the POST request can be seen in browser through the developer tools, somebody can use the app engine URL to post similar data from the browser console.( like in firefox, we can resend the URL. Chrome also has this features i guess)
A few options I see here is,
Use the firewall setting to allow only my domain to send data to the GAE.
This can still fail me since the requests can be made from the browser console repetitively)
Use a WAF ( Web Application Firewall) as a proxy to create some custom rule.
What should be my approach to secure my GAE service?
I don't think the #1 approach would actually work for you: if the post requests are visible in the browser's development tools it means they're actually made by the client, not by your website, so you can't actually use firewall rules to secure them.
Since requests are coming into the service after fundamentally originating on your own website/app (where I imagine the clicks in the mentioned sequences happen) I'd place the sanity check inside that website/app (where you already have a lot more context info available to make decisions) rather than in the service itself (where, at best, you'd have to go through loops to discover/restore the original context required to make intelligent decisions). Of course, this assumes that the website/app is not a static/dumb site and has some level of intelligence.
For example, for the case using browser development tools for replaying post requests you described - the website app could have some 'executed' flag attached to the respective request, set on the first invocation (when the external service is also triggered) and could thus simply reject any subsequent cloned/copy of the request.
With the above in place I'd then replace sending the service request from the client. Instead I'd use your website/app to create and make the service request instead, after passing through the above-mentioned sanity checks. This is almost trivial to secure with simple firewall rules - valid requests can only come in from your website/app, not from the clients. I suspect this is closer to what you had in mind when you listed the #1 approach.
The Application
In short, the application surfaces data from a backend onto a web page. The client application is a Single Page Application made using AngularJS. It calls an ASP.NET Web API service located on a different domain to retrieve the data. I utilize BreezeJS on both the client application and the web service to manage this data. The client is hosted on a SharePoint Online site, and the service is hosted on IIS7.
The Error
I encounter an "Access is Denied" error when AngularJS attempts to make an XMLHttpRequest.open() call targeting this web service. However, though this seems like a simple CORS issue, it has some peculiarities which have me stumped:
Foremost, this error only occurs when using Internet Explorer 11 (or a previous version). When the application is viewed in Chrome or Firefox, it can connect and retrieve data from the service.
The web service is configured to accept the calling origin.
No network traffic is detected either by the native IE development tools or by Fiddler.
Specifically, the line: xhr.open(method, url, true); of the angular.js file throws this error.
Does anyone have any insight as to why this error occurs?
Also, if more specific details are needed I certainly can provide them. I'm not even sure where the issue might be coming from and I don't want to dump tons of irrelevant lines of code.
I think that this is due to using "localHost", i.e when attempting to access a resource in the "Local intranet" zone from an origin in the "Internet" zone.
See: Access denied in IE 10 and 11 when ajax target is localhost
This is not just a localhost issue as previously suggested. I have a production AngularJS application that is trying to POST to a public Web API 2 on a different domain. IE11, Chrome, and Firefox work without a hitch when the site is accessed externally. When accessing from a subnet that can talk directly to those servers, I get Access Denied and IE doesn't even send the request (Chrome and Firefox work flawlessly, of course. One workaround (I refuse to call this a fix) is to add the site as a Trusted Site in IE11. Even when the security settings for Internet mirror the settings for Trusted Site, I get access denied. I have to add the site on each internal IE system to gain access.
I've set up oauth and am properly retrieving an access token.
Here is the response I get from hitting
https://www.google.com/accounts/AuthSubTokenInfo?access_token=<token>
parsed_response="Target=645428735890.apps.googleusercontent.com\nSecure=false\nScope=https://www.googleapis.com/auth/userinfo.profile\nScope2=https://www.googleapis.com/auth/userinfo.email\nScope3=https://www.googleapis.com/auth/glass.timeline\nScope4=https://www.googleapis.com/auth/glass.location\n"
which I believe properly shows that I have requested the correct permissions.
A call to
https://www.googleapis.com/mirror/v1/timeline?access_token=<token>
yields:
"errors"=>[{"domain"=>"usageLimits", "reason"=>"accessNotConfigured", "message"=>"Access Not Configured"}]
Having trouble figuring out what this means. I don't have an actual piece of glass hardware. The docs make it seem like this access token would allow me to make any requests to the mirror api.
Is there an additional setup or permission I need to ask for that I missed? On the application side? Is this related to my google account and having not set up glass?
EDIT:
Okay, from the authorization docs:
Select the Services tab in your API project, and enable the Google Mirror API.
However, I'm not seeing Google Mirror API listed on the services tab?
The Mirror API is currently in developer preview and access is limited to I/O Explorers who have received their Glass device. You can subscribed to this issue on our issue tracker to get updates on when the Mirror API will be public.
Hi fellow appengine developers,
we have a major impact issue on an european bank application, which is their first Google Apps and Google Cloud experience. We'd need this to be addressed to keep the trust that Google can provide the service. Is there any option to get such a major issues fixed in a reasonable time? Preferably other than paying for a premier account, which is not needed for this pilot product at this time.
The issue was already reported on appengine public issue tracker for over a month: http://code.google.com/p/googleappengine/issues/detail?id=7979
App Engine returns 403 on http://customdomain.example.com, instead of redirecting it to https, when secure:always is set in app.yaml. Authentication for the application is set to Google Apps domain, which may (or may not) play role in triggering the issue.
http://appid.appspot.com redirects correctly to https://appid.appspot.com
http://customdomain.example.com -> returns 403
https://customdomain.example.com -> works
Thanks for a beautifully designed service otherwise
Jan
Update:
The issue has proven link to Google Page Speed service. Whan disabled in application console, the redirect works ok. When re-enabled, it fails again.
The issue is observed on production application with PageSpeed, VIP SSL, Google Apps domain authorization, Google Apps data set to store in EU Data Centers only.
The issue is not observed on testing application with PageSpeed, SNI SSL, Google Apps domain authorization, without EU data location restriction.
As a temporary workaround, we commented out secure:always for the site entry url's in app.yaml, and decorated their handler methods with https://gist.github.com/3974365.
There's also google group discussion, if you have similar issue, or look for solution.
https://groups.google.com/d/topic/google-appengine/w3aKx9KxYoU/discussion
Maybe this will help, until the issue is fixed. In webapp2 you can restrict URI schemes. This means: when you allow http and https, you can define two routes for http and https and redirect to https if http was chosen.
Webapp2: http://webapp-improved.appspot.com/guide/routing.html#restricting-uri-schemes