Develop Reference

Intercepting Filter pattern

I need to implement intercepting filter pattern in JAVA to find if the password entered is as per the requirement. For this I can create a filter class.
But how do I handle the situation when password is incorrect, should I pass it to the target class or return false from filter class.
I was following some online tutorial to authenticate request but in that they have not mentioned what to do when authentication fails.
Also I don't think my understanding of target class is correct, for me the target class is something which is called after all the filters show that the request is authenticated.

Does Filter mean HTTP Filter? Is this a web UI? If yes, I think the right course of action would be to mark the request as unauthenticated and route them to an appropriate page with the HTTP response code set to 401 or 403.

I guess it is a MVC application with Jsp as front end where the user will enter the password.

Jersey: How to redirect/forward WITHOUT URL changing in address bar

I am using Jerysey's implementation of JAX-RS to write a REST API. My POJO that handles the get requests eventually forwards it to a JSP. Everything is working fine, the problem is that the forwarding causes the URL in the browser's address bar to change to the URL that the request was forwarded to. How do I do a redirect WITHOUT this URL changing in the address bar? Current, I have tried 4 different ways:
return Response.seeOther(uri).build(),
return Response.temporaryRedirect(uri),
//thrown exception:
throw new WebApplicationException(response),
return Response.status(303).location(uri).build();

It doesn't sound like a Jersey issue per se. Jersey is doing its part to receive the request, do some processing, and return the response you are expecting.
It sounds more like a servlet container issue. Why don't you want the url to change in the browser?
Restful services can (and should) be built with no concern about templates/JSPs/consumers. Take a look at a library like RestAssured, write some tests for your work, and you will see that it is acting as expected.
Instead of rendering out to a JSP, consider using a rest client to make straight http requests against your service.
If you want the url to remain unchanged, consider making the http call using an AJAX library (JQuery or other Javascript-based solution).
I hope that helps!

A RESTful resource is identified by a URL. So if you redirect to another resource with another URL the URL in the address bar should change. That's good because you can e.g. bookmark this URL or send it per eMail.
The question here is are you really redirecting to another resource or do you only want to return a different representation (HTML instead of e.g. JSON). If the latter you should not redirect. Let your resource-class directly return text/html by using Jerseys Viewables.

You could make the entire website inside an iFrame and load the new site into that frame. It will maintain the page URL and load your content.
http://www.w3schools.com/tags/tag_iframe.asp

Several different login forms for Spring Security

I'm using spring-security web authentication with spring-mvc with a custom authentication and all is well so far:
My problem is: /login loads a view with a fully-featured page, but now I have to provide authentication for iframe/popup format (e.g. for an authenticated bookmarklet), so loading a different view (or with different parameters).
I see two solutions that are not overcomplicated:
In my /login action, I have a way (unkown to me so far) to retrieve the original request and check it against a set of URLs that use the simpler view, then choose the matching view. => How do I retrieve this original request?
I make another login action/form, say /login/minimal, which also POSTs to the spring security URL /j_spring_security_check, but I need to implement the request storage/retrieval mechanism, so that the original request is performed after successful login. => I see this has something to do with SecurityContextPersistenceFilter, yet I don't know how to implement it or call it.

If I understand your question correctly, you're looking to vary the login page based on the original request string. Check out this forum post for accessing the original request url from the session. It's for an older version, but you should be able to use it to get started.
Edit I haven't had a chance to validate this, but it looks like the key changed between Acegi security and Spring Security 3. It looks like you can access it from session using the constants in the WebAttributes class. Effectively
//request is a HttpServletRequest object
SavedRequest savedRequest = (SavedRequest)request.getSession().getAttribute(WebAttributes.SAVED_REQUEST);
String url = savedRequest.getRequestURL();

For your first question:
there is a class org.springframework.security.web.authentication.WebAuthenticationDetails
It contains only the IP of the client and its Session, but
it has a method
protected void doPopulateAdditionalInformation(HttpServletRequest request) {}
I belive you could enhance this by subclassing and add the request url. -- But check first if the request is the request from the login form, or the "blocked" request.
Added
Chris Thompson posted an other part of the puzzle to answer your question:
He mentioned that the saved request can be obtained from the session:
//request is a HttpServletRequest object
SavedRequest savedRequest = (SavedRequest)request.getSession().getAttribute(WebAttributes.SAVED_REQUEST);
String url = savedRequest.getRequestURL();
So you can combine this, instead of enhanding the WebAuthenticationDetails you just need to read its already inclueded session.
#see Chris Thompson answer

How to implement complicated servlet mapping in web.xml descriptor

I faced with next task: I have an host, for example host.com and web-application on it.
Application written on Java (JSP/Servlets+Struts2).
I need to implement such HTTP-request to servlet mapping: if user enters address in browser like http://host.com/admin.action, where admin.action - existing action, defined in struts.xml, then render those struts2 action for user. If user enters something like http://host.com/abra-kadabra, (action abra-kadabra notdefined in struts.xml), then pass this request to some servlet or struts action.
Can somebody advice how to do such thing?
Thank you!

You could use Tuckey's very powerful URLRewriteFilter. i.e.
<rule>
<from>^/abra-kadabra$</from>
<to>/admin.action</to>
</rule>
This rule would forward all browser requests on "/abra-kadabra" to "/admin.action" transparent to the user.

Servlet specification doesn't give you many options. You can map your servlet to specific path (/some/specific/path), to all paths under some hierarchy (/dir/*) or to some extension (*.action). Best what you can do is to map your servlet to *.action, and then determine action to be executed based on request.getRequestURI() or request.getServletPath().

How do I create a new HttpSession in a RESTful webapp?

I have a need to create a HttpSession (via cookie) whenever a client invokes a particular UI.
Assumptions:
Let's assuming that I'm not going to worry about any deep oAuth-like authentication dance. JESSIONSID cookie impersonation is not an issue for now.
The server is tomcat, thus a JSESSIONID cookie is sent down to the client if a new session is created.
Design issues:
I'm grappling with how to design the URI. What is actually the REST resource ? I already have /users and /users/{someuserid}. I wanted to use /auth/login but in one previous SO question, one cited article says that we should not have verbs in the url. I've noticed that even Google makes the same mistake by having https://www.google.com/accounts/OAuthGetRequestToken. So in your opinion, are /auth/login/johndoe (login) and /auth/logout/johndoe (logout) good options ?
UPDATE:
I've changed my design. I'm now thinking of using the URIs /session/johndoe (PUT for login, DELETE for logout). It should still be within the limits of the REST ethos ?

Aren't sessions irrelevant in REST Style Architecture?
http://www.prescod.net/rest/mistakes/

I am in the midst of creating a REST endpoint that recognizes sessions. I've standardized on:
POST /sessions => returns Location: http://server/api/sessions/1qazwsxcvdf
DELETE /sessions/1qazwsxcvdf => invalidates session
It is working well.