I have a requirement as below
User makes a request to access welcome.html. In the process of request, we are also posting userid.
Once the request reaches to the server, first think i need to check if user present in my DB or not, in case it is not present, then i have to redirect to the login page and incase user is already present in my db, need to create new session and redirect to welcome.html.
I am not sure, how can I achieve this functionality.
Looking for some idea.
thanks
Adi
Related
I have created a Login Application with struts 2 and integrated with SSL. When I click on the back button after logging out, I am still able to see the page though it shows session expired when I try to perform any action on the page. But, when I refresh the page, I am able to perform all the actions on the page. I have removed the cookies using an Interceptor on the event of LogOut. Can anyone help me out.
This is not much information that you give us here.
I think the problem might stem from the URL of the page that you are refreshing. Please take a look at that and what action that URLs gets called, and all the GET and POST data that is appended when reloading the page. You might want to use a debugger for this. Maybe this information regenerates the cookie or the logged-in information in the session.
You can use the SessionAware interceptor to store data based on the uses's session. If you don't find the error, you can put a boolean loggedIn flag into the session, check at the beginning of your actions if the user is really logged in, and set the value to false when the user logs out.
We have some shopping cart pages which work with both guest and user paths. We want to allow a user to login at any time during the process but don't really want to create yet another login page. I'd prefer that we can simply redirect the user to the existing login and tell Spring Security what URL to come back to.
I know this happens automatically when sessions timeout and/or protected pages are requested without a session, but is there a way I can give the URL to Spring Security myself?
If you just need a simple return-to URL to retrieve the cart, then you are probably best to implement that yourself in an AuthenticationSuccessHandler. You can look at the source for SimpleUrlAuthenticationSuccessHandler and its parent for inspiration.
The default login mechanism uses the RequestCache and a SavedRequest, but that is intended to actually replay a request which would not otherwise be authorised. That's probably overkill in your case.
I'm using PrettyFaces 3.3.3. I have a requirement that if a user tries to view a page, but is not logged in, they are sent to the login page, and then redirected to the original page they wanted to view. Just wondering what would be the best approach for this.
You probably want a security framework here. The basic idea is that you'd want to intercept the requested URL in your security filter, save it into the user's session, then once authentication is complete (e.g. user has submitted the form with their credentials, or whatever mechanism you're using) you retrieve the saved URL from the user's session and perform a 302 Redirect to it.
This is not something PrettyFaces will help you with directly, except that you can use it to capture the URL more easily using PrettyContext.getCurrentInstance(request).getRequestURL();
There is an article about this here: http://ocpsoft.org/java/jsf-java/spring-security-what-happens-after-you-log-in/
Using OCPsoft Rewrite (core of PrettyFaces 4) you can do this programatically as well, and even do the authentication directly in your security rules or annotation config: https://github.com/ocpsoft/prettyfaces/blob/master/annotations/src/test/java/org/ocpsoft/prettyfaces/annotation/jaas/JaasRolesBean.java
This is an upcoming feature but is not yet complete - we would love feedback.
I know that I can use annotation or Request mapping to restrict access to an ACTION by some specific ROLES. But now I have a different circumstance.
My scenario is: every user of my site can create posts, and they can make their own post public, private, or only share to some other users. I implement sharing post by a database table PERMISSION, which specify if a user have the right to view a post or not.
The problem arises here is that when a customer access a post through a direct link, how can I determine he/she have the privilege to view it? There's 3 circumstances:
The post is public, so it can be viewed by anyone (include not-login
user)
The post is private, so only the login-owner can view it
The post is sharing, it means only the login-user that is shared and the
owner can view it.
I want to process like this:
If the requested post is public: ok.
If the requested post is private/sharing: I want to redirect
the customer to the login page; after
logging in, the user will be re-direct
to the page he wants to see.
The problem here is that I can redirect the user to login controller/ auth action, but after that I don't know how to redirect it back. The link to every post is different by post_id, so I can't use SpringSecurityUtils.securityConfig.successHandler.defaultTargetUrl
Could anyone know a way to do this?
Dunno about grails, but spring security has a spring-security-redirect parameter which can be used to redirect the user to the specified url on successful authentication.
I think you could add your own filter that will be executed before the action is called and do the verification of the post permissions there. You can find more information about Grails Filters here.
Have you looked at the Grails Spring Security ACL plugin? I don't know it very well, but it's designed to restrict access to particular instances:
http://grails.org/plugin/spring-security-acl
I have found a quick workaround for this problem:
If the user is logged in: check the user's privilege, and return the appropriate result.
If the user is not logged in: At view action, set the post_id by:
session.post_id = 8
Redirect the user to the Login Controller/ Auth action.
At checkrole action(which is my grails.plugins.springsecurity.successHandler.defaultTargetUrl in Config.groovy), if session.post_id exists, use it to build the link for re-directing to the view action. Before redirecting, clear the session.post_id.
We are attempting to integrate an ASP.NET MVC site with our client's SSO system using PingFederate. I would like to use the built in FormsAuthentication framework to do this. The way I've gone about it so far is:
Set up my Web.config so that my FormsAuthentication LoginURL goes to my site's "BeginAuthentication" action on a "Security" controller. From this action, I set up some session variables (what URL was being accessed, for example, since Ping won't send this info back to me), and then redirect to our client's login page on an external site (www.client.com/Login for example).
From here, the authentication takes place and a cookie is generated on the same domain as the one that our application is running on which contains the unique identifier of the authenticated user, I've set it up so that once this happens, the Ping server will redirect to my "EndAuthentication" action on my "Security" controller.
In this action, I call my membership class's "ValidateUser" method which takes this unique identifier from the cookie and loads in the user on our application that this ID refers to. I save that logged in user in our Session (Session["LoggedInAs"], for example) and expire the cookie that contains the id of the authenticated user that the SSO system provided for me.
All of this works well. The issue I'm wondering about is what happens after our user has already authenticated and manually goes back to our client's login page (www.client.com/login) and logs in as another user. If they do that, then the flow from #2 above to number 3 happens as normal - but since there already exists an authenticated user on our site, it seems as though the FormsAuthentication system doesn't bother kicking off anything so I don't get a chance to check for the cookie I'm looking for to login as this new user. What I'd like to do is, somewhere in my Global.asax file (probably FormsAuthenticate_OnAuthenticate), check to see if the cookie that the SSO system sends to me exists, and if so, sign out of the application using FormsAuthentication.SignOut().
Another issue that seems to be related is that if I let my Session expire, the FormsAuthentication still seems to think I am authenticated and it lets me access a page even though no currently logged in user exists in my Session, so the page doesn't render correctly. Should I tap into the Session_End event and do FormsAuthentication.SignOut() here as well?
Basically, I want to know when the authentication ticket created by
System.Web.Security.FormsAuthentication.SetAuthCookie(..) gets checked in the flow of a request so that I can determine whether I need to SignOut() and force revalidation or not.
Thanks for any help. Sorry for the length of this message, trying to be as detailed as possible.
Mustafa
Welcome to the small section of Hades that is mixing session with formsauth.
If your needs are as complex as presented, you would get more sleep if you implement a full provider stack to share amongst the participating sites. Easier said than done, I know.
But to address your question:
from http://www.codeproject.com/Articles/39026/Exploring-Web-config-system-web-httpModules.aspx
On the way in....Check ticket and set identity #
app.AuthenticateRequest += System.Web.Security.FormsAuthenticationModule.OnEnter-->OnAuthenticate
On the way out... set the ticket and redirect as necessary
app.EndRequest += System.Web.Security.FormsAuthenticationModule.OnLeave
Reflector is your friend. ;-)
I don't know about a specific event for when the cookie is checked, but you could place the appropriate logic in Application_BeginRequest() and check the user's authentication state there.
Another issue that seems to be related
is that if I let my Session expire,
the FormsAuthentication still seems to
think I am authenticated and it lets
me access a page even though no
currently logged in user exists in my
Session, so the page doesn't render
correctly.
The life of the cookie (how long until ASP.NET feels it needs to ask for a password again) and how you are managing state are unrelated. The ASP.NET authentication is cookie based so that, should a developer want to, he could turn off viewstate, session, use no query strings or hidden fields and authentication still works.
If you want to tie the interval at which you request the password to how you are persisting data, then you will want your session expiration to be roughly the same as the cookie expiration, but they will never quite match up. It would be better to have two policies (one for how fast you throw away a users session data and one for how long you are willing to wait before you need to reask for a password)