I am using Spring Boot with Spring Security and authentication is OAuth2.I have separated authentication, resource and front server.
My problem is after logged in system can not redirect to main page or home page. its going to random image page like (localhost:7080/app/img/search.png)
But after logged in and than system redirect to random page, if i make request directly to main page localhost:7080/app/#/platform, its ok. it can open main page.
Access token and refresh token is exist and valid on MongoDB. I am not sure but it looks after logged in, front server or resource server can not redirect the user to the main page.
I dont know who is the responsible this redirection, Front-end configuration or front-end code ? Resource server config/code or authentication server ?
what should i see on DB when i check the access token and refresh token.
There is too much config code and file, i dont know how can I show all of them. I hope someone can help me.
In such situation browser network logs will help you.
After login check while redirecting from authentication server whether it has proper location in Location header.
If location is right as per the configuration then problem will be in client server else need to check in Authentication server.
Hope it will give proper direction to investigation.
Related
I have a web app that uses firebase for auth. Once a user signs up/logs in there is always a certain cookie present.
I would like to, based on the presence of that cookie, redirect the user from the root path to a sub path i.e. site.com=>site.com/app whenever they visit the site.
I'm using Netlify to host my site and I've read through their documentation
but I can't figure out anyway to do this. It appears as though the only "conditions" that can be used for a redirect are langauge & role, but nothing about cookies.
Maybe this is possible using JWT Roles?
It's not possible today, but you can keep an eye on this thread: https://community.netlify.com/t/expanding-functionality-of-redirects/988/36?u=goleary
I have a Spring Security app that uses SAML. It is working fine. I go to a secured page, I get redirected to the IDP, login... success.
Now I want to have the login done "in house" as it were, with no redirection.
I want to have a login page that takes username/pass - then -- well I don't know. :)
Is there anyway to NOT have the user's browser go to the IDP, either POST the form to the IDP and then redirect back to my app?
I read in the documentation about back-channel SOAP calls, and that sounds like exactly what I want, but I can't find anything on it. Does anyone have an example of how this would be achieved?
Iam new to gadgets.
Iam using the oauth2 example for facebook authentication which is bundled with Shindig 2.5.0
The file is under /gadgets/oauth2/oauth2_facebook.xml
I don't know whether this is an issue or not?
I created a gadget container like commoncontainer is created.
Inside the gadget url i have given the above facebook gadget url.
I have created a facebook app and i have configured all the details in oauth2.json file.
When the gadget is rendered, it is asking for facebook username and password. After that it is returning some data.
The main problem here is, after this whenever i access the same gadget over the container it is not asking for the facebook credentials. Simply it is logging with the earlier credentials(I donno how the conainer is storing). Even I access the same gadget in other browser also, it is not asking for creadentials.
I googled it but i didn't find anything regarding this.
Even after deleting all the cookies in the browser, it is not asking for the credentials unless I restart the app server.
Please help me on this.
Is there anyway restrict this kind of behaviour?
Shindig stores the access token on the server. In a production implementation the access token would be stored by individual user, but the sample implementation does not have this concept right now. OAuth access tokens are usually long lived, so the user should not have to go through the oauth dance for a while. Once the access token expires you would have to do the dance again.
Here are my pages:
Login Page: if user login info is valid, redirect to destination URL(ex: https://int63.xyz.co.uk/base/page/mydetails.jsp) else display login page
LoginServlet Page: if user has an open session, redirect to the proper resource else redirect to login page
Destination URL: It redirect the request back to the Login Url which then makes it a repetitive call.
In the above scenario when I clear my browser history and cache and then hit the target page it gives me the login page as expected. But when I enter correct details it goes into an infinite loop(That's what I can capture in logs).
The request is getting successfully authenticated on login page and sent across loginservlet page well. But I am unsure about what processing is made at the application end and why it redirects back to the login page.
Any ideas how I can solve this problem?
We dont use any .htaccess file instead we follow the mechanism of Identity and Access management wherein we create junctions and control the access to them through ACLs.
Thanks all for the help provided on this issue.
I figured out what was the problem with this.
When I said it was making a redirection loop it was because of cross domain request forwarding. It was authenticating the users on abs.com and was sending the request to some abs.co.uk so the page on abs.co.uk was not able to recognize and was sending the request back to abs.com which again forwarded the request to the same page as it has already authenticated this user.
So this cross domain forwarding of request was a reason of this loop which I then made changes to get it worked in same domains.
I have this GWT application which login/logout to a server.
The server side is ok as it can login/logout a connection.
However I need that when the application login in with a browser, the application will stay logged in for each new instance of the application.
Use cookies on the browser to store login details. When a new tab is opened, and requests the page from the server, the cookies will be passed along automatically and you can log the user in from there.
Make sure you understand the security implications of storing login details in cookies before deploying this strategy!
You could store the information if a user has been successfully authenticated in the http session on the server side and provide a service like
public boolean isAuthenticated();
which checks that property.
Before showing any sensitive information in the client, call that service to make sure, the current user is authenticated. I would recommend not to store login credentials in a cookie.