We have moved our development to CA1 Connections Cloud environment and started setting up our application.
I create a new Internal Application in the admin interface with OAuth2. After that I tried retrieving the application credentials using the Show Credentials button.
This resulted in a page refresh and all I got was an unstyled html page with navigation only, no other messages and no credentials. After clicking the back button I get an error message "Unable to fetch credential info."
Clicking Reset Credentials or changing auth type to OAuth1 behaves the same.
Is there anything I can do to work around this issue?
Thanks
Related
I'm tasked with making a server using Node.js which will read emails from a Google account and parse the content from those emails into data we can store in a database. I'm using Google's googleapis package (v103.0.0) in NPM to authenticate/authorize with whichever account we'd like to use.
The issue comes when we try to switch accounts and have the user re-auth. During development on a local machine, the Auth process works as expected:
The client requests an Auth URL.
The server generates a new Auth URL and sends it back to the client.
The client redirects to that URL and the Google Consent Screen is shown.
The client is asked to choose between logged-in Google accounts.
The client authorizes the application and is redirected back to the server with a code.
The server uses the code to generate/save a token, which allows it to use the Gmail API.
However, after deploying to Heroku, the Google Consent Screen no longer allows the user to select an account. Instead, at step 3, it shows this message. In just about every other question related to this error, there's always additional information below the error code/message, but nothing's there for me. I made sure: (1) the domain I'm using in Heroku is verified on the Google Cloud Console, and (2) the redirect_uri within the Node.js application is passing the correct domain to the Auth URL, even while in production.
I can't provide the URL for privacy reasons, but let me know if there's any source code or Cloud Console info I should include.
It didn't take long after posting this question, but I realized I was using an incorrect OAuth 2.0 Client ID type. I was attempting to use "Desktop" when I should've been using "Web application" instead. Take a look at this image to see the difference.
When you select "Web application", you're given some new options: Authorized JavaScript origins, and Authorized redirect URIs. This is where you need to fill out the allowed URIs. Here's a sample of what that should look like.
In our project we've built an Azure Function which launches Puppeteer in headless mode, goes to our webpage and takes a screenshot of the page which is then emailed out as pdf report. Works locally and deployed to Azure. That was the POC though. Now, we're moving to production and introduced authentication (Azure AD B2C, single tenant), will run each http request via APIM etc.
What happens now:
our Function app was registered in AD as a daemon and receives an access token.
this access token is inserted into 'Bearer ' Authorization header in Puppeteer (page.setExtraHTTPHeaders)
headless browser does not get authenticated and screenshot we receive is of the login screen (Azure SSO)
What needs to happen
we need to convince the react-msal library our FrontEnd is using to authenticate users, that the headless browser should get authenticated and allowed to render the page
The solution I've come up with so far is to replicate msal-react's logic of saving session information into Puppeteer's session storage, so that when msal-react checks for persisted session it will find it and allow headless chromium in. I'm yet to implement it. I'm curious if anyone in the community has experience building something similar.
Initially I have setup microservice application with oauth2 and keycloak.
I was able to do that successfully. I have added all things such as SECURITY_OAUTH2_CLIENT_ACCESS_TOKEN_URI, SECURITY_OAUTH2_CLIENT_USER_AUTHORIZATION_URI, SECURITY_OAUTH2_CLIENT_CLIENT_ID, SECURITY_OAUTH2_CLIENT_CLIENT_SECRET, SECURITY_OAUTH2_CLIENT_SCOPE, SECURITY_OAUTH2_RESOURCE_USER_INFO_URI. I have jhipster registry running and gateway application running. I have created a application in okta with the openidconnect type application. Screen shot is mentioned below. I able to see the http://localhost:8080. Upon clicking on sign in button I getting the below error.
If you look in your browser’s address bar on the 400 error page, you’ll see it has “http://localhost:8080/login” as the redirect URI. Add this value to the Login redirect URIs in your Okta app and you should be good to go.
Thanks, I solved the issue. The solution was, The user with which i was trying to login was not created in users table. For that I have created another user in okta and assigned the roles to it. Reset the password and tried logging to account. Upon invoking "http://localhost:8080" and clicking on "sign in" button it redirected to okta login page and logged in with the above created user and it redirected me to home page of my gateway.
Thank you
So I'm working on a project to redeploy an application that was previously hosted as an Azure Mobile Service as an Azure Mobile App. Said application has a frontend (hosted as a Web App in Azure) and backend API (this is the Mobile App) that is called directly from the frontend's javascript. The upgrade had been going well up until I started working on the Microsoft Account Authentication piece. Following the instructions at...
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-net-upgrading-from-mobile-services
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-how-to-configure-microsoft-authentication
...got things mostly rolling. My application has been registered in the Microsoft Account Developer Center, I specified a Redirect URI following the 'https://{{my_backend_mobile_app_name}}.azurewebsites.net/.auth/login/microsoftaccount/callback' format, I configured the Microsoft Authentication/Authorization in the appropriate blade of my mobile app in Azure using the ClientId/Secret from the Microsoft Account Developer Center. Things go mostly well when I test it out: I can go to the frontend of my application and click on the 'Sign In' button, a new window opens with Microsoft's Login.Live site where I am prompted to login with a Microsoft account, I do so successfully and am redirected to the Redirect URL specified in the Microsoft Account Developer Center and it has Code and State values appended in the query string.
However, the page that is shown when I get redirected there is a 'You do not have permission to view this directory or page'. If I copy the URL, open a new tab, paste it in and hit enter it takes me to a 'You have successfully signed in' page. But neither way takes me back to the frontend of my application where it would log me in and continue into the site as everything is still happening in the new window that was opened for signing in. If I close that window, the authentication process sees that as a 'Cancelling' of the login and requires me to login again (which just repeats the above process). If I leave the window open and go back to the window with my frontend site, it is still waiting for a response from the login process.
So this leads me to my main question: How do I get the Microsoft Account Authentication process to actually return the login response to my frontend site rather than to the login window?
Side note, I've updated the SDK's for both the frontend and backend from the Mobile Service ones to the Mobile App's ones. In doing so I had to add in an OWIN middleware (per the instructions in link #1 above, under the 'Updating the server project' header) to my backend app. My current hypothesis is that this OWIN middleware isn't configured correctly for authentication and is getting in the way blocking the callback from working properly; thus, I am messing around with the app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()); piece.
According to your description, I assumed that you are using the JavaScript client library for Azure Mobile Apps. I checked this issue on my local side and found I could encounter the same issue as you mentioned as follows:
Then I tried to deploy it to azure web app (https://brucechen-mobile.azurewebsites.net/login.html), I found it could work as follows:
After searched the web I found a similar issue and refer to this blog about Fix the Ripple Issues. I log onto azure portal and choose my mobile app, then click "All Settings > CORS", add the URL for my local web application as follows:
Then, click "SETTINGS > Authentication / Authorization", add the ALLOWED EXTERNAL REDIRECT URLS as follows:
Based on the above settings, it could work as expected on my local side as follows:
I think that I have configured web SSO (SPNEGO) on our test 8.5.3 server. I created a test discussion data base and when I access it with a web client my credentials are displayed. But if I acces my Xpage first the #Username function shows Anonymous. If I display the discussion page first then return to my Xpage the #Username gives the correct name.
Any ideas ?
I would check the ACL of the databases and see what anonymous is set to.
I suspect that in the discussion anonymous is set to 'no access' so it triggers the login process via SPNEGO and logs you in with your credentials but the XPage app may have anonymous set as reader so it is just letting you in as anonymous.
When you access the discussion before the xpage app the ltpatoken SSO cookie is being set so when you hit the xpage app it knows your logged in via SSO which is why it is showing the correct credentials in that case.