Problem with Filters in web application

[fdevelop]

Hi all,
I have a problem using a filter in my web application. The filter is
supposed to be run each time a page in the secured/ directory is called
(this works). It checks whether a specific object is present in session
scope and if not it should redirect the user to the login page. Thís
works fine for the first time. When I am on the secured page and click
another page ouside of the secured directory and click back on the
secured page the filter is run and finishes successfully but the page
is blank. Does anybody know what the problem could be?

Thanks in advance,

polsa

 

[John C. Bollinger]

I have a problem using a filter in my web application. The filter is
supposed to be run each time a page in the secured/ directory is called
(this works). It checks whether a specific object is present in session
scope and if not it should redirect the user to the login page. Thís
works fine for the first time. When I am on the secured page and click
another page ouside of the secured directory and click back on the
secured page the filter is run and finishes successfully but the page
is blank. Does anybody know what the problem could be?

Chances are that one or more of your pages are buggy. (I'm assuming JSP
pages here.) To work it out you will probably want to make your servlet
and your pages log some diagnostic output. You may find a clue in the
information that already is logged. The most likely scenario is that
the unsecured page removes or alters session- (or application-) scope
objects in a way that either the filter or the secured page is
unprepared to handle, but to work out the details you need a way to
trace the processing. (Hence the logging.)

 

[fdevelop]

Hi,
thanks for the answer. But if the unsecured page would manipulate the
session the filter would not pass since the object is not in the
session anymore. Therefore this case imho is very unlikely. any other
ideas?

polsa

 

[John C. Bollinger]

thanks for the answer. But if the unsecured page would manipulate the
session the filter would not pass since the object is not in the
session anymore. Therefore this case imho is very unlikely. any other
ideas?

Is it possible that the unsecured page replaced the security object with
a different object bound to the same name? Is it possible that the
unsecured page modified the existing security object? Are there any
*other* objects stored in session- or application-scope that your
secured pages rely on, whether directly or indirectly? The fact that
the filter passes requests that are subsequently processed incorrectly
does not disprove the hypothesis I offered, which still seems the most
likely to me.

Other, less likely, possibilities include these:
() The unsecured page sets a cookie that confuses the filter or secured
page(s).

() The unsecured page corrupts server state in some way -- mucks up
static variables used by the secured pages, for instance. (Note that
reliance on such variables is poor practice in the first place, as are a
host of other things that would make this general scenario possible.)

() You are mistaken about the filter "finish[ing] successfully." The
behavior you see might result from a path through the doFilter() method
in which the end of the method was reached without anything being done
with the request (not passed down the chain, not forwarded, not
redirected, and no explicit error response). This is not so unlikely a
scenario, except inasmuch as it contradicts your assertion that the
filter does finish successfully (by which I take you to mean that it
passes the request down the chain).


To figure out what is really happening, do what I told you to do in the
first place: log the application's behavior.

 

[fdevelop]

Hi,
what I meant by "finished successfully" is a logging statement I have
in my Filter which prints out "finished successfully" if the object was
found in session scope. I have done some more logging and cannot find
anything spectacular. The only question left to me is: what I do is:

if (!object exists) {
redirect to login page;
}

I don't do anything if the object exists. Is this a problem. Should I
call any method if everything is fine and I want the requested page to
be shown? This is the first time I am using filters so I am not very
confident with them.

Thanks,

polsa

 

[John C. Bollinger]

Hi,
what I meant by "finished successfully" is a logging statement I have
in my Filter which prints out "finished successfully" if the object was
found in session scope. I have done some more logging and cannot find
anything spectacular. The only question left to me is: what I do is:

if (!object exists) {
redirect to login page;
}

I don't do anything if the object exists. Is this a problem. Should I
call any method if everything is fine and I want the requested page to
be shown? This is the first time I am using filters so I am not very
confident with them.

You haven't shown any real code, so all of my comments so far are
somewhat speculative. Nevertheless, I see two problems with your approach:

(1) This is a minor problem, but what if some unsecured page in your
application performs a

session.setAttribute("security.object.name", new Object());

? Does your application continue to work as expected? (That is, does
any part of it care *what* object is bound to the session, or is the
fact that *any* object to the specified name all that matters?)

(2) The major problem is that your filter is broken. If it is really
written as you describe, then it should block ALL authenticated traffic
and redirect any unauthenticated traffic. Perhaps that's what you're
actually seeing? For instance, are you sure that the successful
secured-page views you have seen have actually come through the filter?

The servlet spec (2.4) and API docs both say that a filter is
responsible for passing the request and response on down the chain
unless it wants to block other request processing. You accomplish this
by invoking the passed-in FilterChain's doFilter() method. See
http://java.sun.com/j2ee/1.4/docs/a...t.ServletResponse, javax.servlet.FilterChain)
If you are not doing that then that is likely the source of your problem.

 

[fdevelop]

Hi,

You haven't shown any real code, so all of my comments so far are
somewhat speculative. Nevertheless, I see two problems with your approach:

Sorry for that but my boss wants the complete code to be
confidential...

(1) This is a minor problem, but what if some unsecured page in your
application performs a

session.setAttribute("security.object.name", new Object());

? Does your application continue to work as expected? (That is, does
any part of it care *what* object is bound to the session, or is the
fact that *any* object to the specified name all that matters?)

The other parts of the application work fine. I checked the other pages
whether or not they modify the object but they do not even reference
it.

The servlet spec (2.4) and API docs both say that a filter is
responsible for passing the request and response on down the chain
unless it wants to block other request processing. You accomplish this
by invoking the passed-in FilterChain's doFilter() method. See
http://java.sun.com/j2ee/1.4/docs/a...t.ServletResponse, javax.servlet.FilterChain)
If you are not doing that then that is likely the source of your problem.

I will try that and come back to you.

Thanks alot for your support.

polsa