cofactor
asked on
Intercepting Filter design patterns
Please see this Text
The Intercepting Filter design patterns provides interception and redirection of requests and response where needed. This pattern is applicable in application security and other rule-based access implementations. Implementing interception filters helps manage such complex scenarios by avoiding the necessity of coding access implementations within individual JSPs. One intercepting filter is implemented to handle all access concerns. Interception filters are usually servlets that implement the Filter servlet interface.
>>>>This pattern is applicable in application security
what kind of security ?
where this filter could be used for security ?
is it between view and the controller OR between controller and the model ?
The Intercepting Filter design patterns provides interception and redirection of requests and response where needed. This pattern is applicable in application security and other rule-based access implementations. Implementing interception filters helps manage such complex scenarios by avoiding the necessity of coding access implementations within individual JSPs. One intercepting filter is implemented to handle all access concerns. Interception filters are usually servlets that implement the Filter servlet interface.
>>>>This pattern is applicable in application security
what kind of security ?
where this filter could be used for security ?
is it between view and the controller OR between controller and the model ?
I would say that it is in front of model, view and controller (My understanding of the view is for example JSP Files on the server and not treating the client as view)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
BTW, I agree with ChristoferDutz re: Open questions
<<what kind of security ?>>
See this first
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
http://www.coresecuritypatterns.com/patterns.htm
You can based on the request parameters decide whether to go forward the request to the servlet to which it was originally intended to go to, for example,
-- if the user id passed in the request is not registered/valid, you can forward the request to a error page rendering servlet
-- if the session of the request is not valid, you can forward the request to a error page rendering servlet
-- if the parameter value (say user type) suggest that this particular service (say an admin service is request by a user id of a normal consumer) is not applicable to this user id, you can forward the request to a error page rendering servlet
-- if the parameter values says that this request is coming from an iphone client rather than a desktop one or ipad one, you can render a different JSP or do some tweeking on the response
-- If the request header says that this browser client is not supported, you can show a message by changing the response
-- if the request header says that request is coming from an untrusted netwok and so on
See this first
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
http://www.coresecuritypatterns.com/patterns.htm
You can based on the request parameters decide whether to go forward the request to the servlet to which it was originally intended to go to, for example,
-- if the user id passed in the request is not registered/valid, you can forward the request to a error page rendering servlet
-- if the session of the request is not valid, you can forward the request to a error page rendering servlet
-- if the parameter value (say user type) suggest that this particular service (say an admin service is request by a user id of a normal consumer) is not applicable to this user id, you can forward the request to a error page rendering servlet
-- if the parameter values says that this request is coming from an iphone client rather than a desktop one or ipad one, you can render a different JSP or do some tweeking on the response
-- If the request header says that this browser client is not supported, you can show a message by changing the response
-- if the request header says that request is coming from an untrusted netwok and so on
ASKER
>>>One widely used example of this pattern is the Servlet Filter Chain
you mentioned "chain" ...why ? We could just use one Filter class which could check all security preprocessing.
Is there any specific reason why to use multiple filter classes to form a chain ?
you mentioned "chain" ...why ? We could just use one Filter class which could check all security preprocessing.
Is there any specific reason why to use multiple filter classes to form a chain ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
One widely used example of this pattern is the Servlet Filter Chain. (http://retail.oreilly.com/pub/a/onjava/2001/05/10/servlet_filters.html)
Assume you have a web-application and you want to access a resource in this application. Now if you want to restrict this access to logged-in users, then you can introduce an intercepting filter, that checks if the current user is logged in. If he is not logged I the filter can decide to send back an error-page instead or to redirect the user to a login-page.