I have a GAE/GWT server web application using OAuth 2.0.
Locally (GWT development mode) it works fine (user is being redirected to the access confirmation page, I get a token and I can call google API using this token).
But when I deploy the application to appspot, it fails. Confirmation page looks differently, token returns in different format and google API doesn't work with this token.
Does appspot support OAuth 2.0? Does anybody experience this?
I've been struggling a lot to find out the issue.
In my case I had normally set my appspot url on the console as an authorized URI just as the localhost one, downloaded the json file and had the same redirect_uri_mismatch error.
The solution was to set an http version of the url. For some reason, it won't work if you set only the https one.
Appspot does not suport OAuth http://groups.google.com/group/opendatakit/browse_thread/thread/45ecd1401867154f/0b83b359c2504a74?show_docid=0b83b359c2504a741
Related
I have angular7 + java web application.
I have configured SSO login for it on a apache tomcat server. Only authentication is done from SSO , Authorization is done using a users table in the application database.
This setup works fine on my local system, Authorization happens for Valid user & invalid user is redirected to access denied page using a custom interceptor typescript code in angular.
But when I deploy this on the server in face an issue. Valid users are logged in perfectly using SSO authentication & application Authorization.
But when I hit the application from an invalid user, it shows the login page with no css applied, instead of the access denied page which it is supposed to redirect to.
In the network I see 500 error for the style.css file and a 403 forbidden error.
There is a problem at your server end, debug your code and fix accordingly.
I think I also faced the same problem when I was updating my data in S3 bucket in AWS,
You just need to fill all empty .css file with something like this :
/* Nothing here*/
Sorry, this problem has many variables so I might not be isolating the problem correctly.
Our website/application is using HTTPS under the Play 2.1.2 framework behind Okta. Okta uses SAML to authenticate. Our Java files for all of our pages (in the Java code) has #RequiresAuthentication(clientName = Saml2Client) so the user is forced to log in with their Active Directory login on Okta to access our site.
We used SAMLTracer on Firefox to determine that the webpage seems to be authenticating with Okta through SAML correctly. The problem we're running into is when using HTTPS, we're getting a 404 error for the main page. The log says:
[ERROR] - from application in play-akka.actor.default- dispatcher-9 oops! page not found: uri = /
As an experiment, we used HTTP instead of HTTPS and we don't get that error and our page loads up fine. The routes file is the same so it doesn't make sense that HTTPS doesn't work but HTTP does with the same routes file. The OKTA config are identical for both HTTP and HTTPS, sans the url (for HTTPS we used https:// and port 8443 instead of http:// and port 8080). What else might be causing this problem?
I managed to get Azure AD Authentication to work by using the sample apps from ADAL4J library from GitHub.
Here it is working.
My question is:
Can the same result be accomplished without the redirect to the Microsoft page?
The customer wants to use his own internal login page.
I'm thinking some sort of behind the scenes POST request to the same URL, and getting the reply. This means my app will see the user credentials, I am ok with that.
Is this supported by Azure AD?
Environment:
Java server side (Spring), AngularJS UI.
Thanks.
The redirect is necessary. Only AAD should be collecting AAD credentials. See this answer for more information on why that is:
How to authenticate user with Azure Active Directory using OAuth 2.0?
I'd like to use the google universal analytics API on the server side. The idea is that there is a browser app showing some graphs which is open to the intranet and doesn't require a login at all. So server either does the login for client and provides the working token to the client or the server provides all the data to the client as well. Oauth login docs and libs from google rely on redirect urls etc which sounds painful for a server-side login . So is it possible and are there any tutorials?
I have a desktop Java application that communicates with a GAE server. The client application signs in to the server using OAuth 1.0 with signpost via the provided endpoints
(appname.appengine.com/_ah/OAuthGetAccessToken and the like) with consumerkey and consumersecret set to "anonymous" and scope set to the GAE domain. The login process appears to be working fine:
Retrieve Request Token
Let the user visit the resulting authentication URL
Ask user for verification code
Retrieve Access Token
At this point, I have a seemingly valid token and token secret. If I use these to sign a request to the GAE server, I get an OAuthRequestException when identifying the user:
OAuthService oauthService = OAuthServiceFactory.getOAuthService();
try {
user = oauthService.getCurrentUser();
if (user != null) {
ri.userName = user.getEmail();
}
} catch (OAuthRequestException t) {
t.printStackTrace();
}
This used to work fine until this morning. I am using a modified version of the Chrome to Phone GAE backend. I noticed that Chrome to Phone is having the same issue: I cannot login to the service anymore, so I don't believe this is an error on the client side. Logins don't show up in the Google Connected Sites, Apps, and Services console. Here is a link to the affected line in Chrome to Phone's GAE service: Chrome2Phone affected source.
I already tried registering the application in the Google API console and provided comsumer key and secret, with the same result.
We made some back end changes to our authentication system which ended up not being compatible with App Engine code relying on the authentication system. It appears to be a rather straightforward issue and we are in progress with a fix. We don't have an exact timeline on resolution yet but expect it to be soon.
Update: the fix has been rolled out to production as of about 8pm PST. Thanks everyone your patience.
This isn't exactly an answer, but I'm seeing the same new behavior on a python app engine app using the built-in oauth provider libs (google.appengine.api.oauth). Existing saved tokens continue to work, but requesting a new token and then using it to call a protected service results in a InvalidOAuthTokenError. This is with unchanged consumer and provider code that worked flawlessly until last night (approximately midnight CST).