-
FEATURED COMPONENTS
First time here? Check out the FAQ!
Hi all,
I am using ZK 3.0.6 and trying to secure my pages with Spring Security 2.0.3.
Here's my security scenario:
I want to a specific page (named XXX.zul) to be accessed only by administrators (ROLE_ADMIN). And the rest of the pages will be accessed by all users (ROLE_USER).
To achieve this, I make the configuration (security.xml) as follows:
<sec:http auto-config="true"> <sec:intercept-url pattern="/XXX.zul" access="ROLE_ADMIN" /> <sec:intercept-url pattern="/**" access="ROLE_USER" /> <sec:http-basic /> </sec:http>
<window title="Another Page"> <include src="/XXX.zul" /> </window>
Hey Henrichen,
Actually my Spring Security configuration is fine. I don't have any problems if I call the pages directly (e.g. if page XXX.zul is only visible to ROLE_ADMIN it is so. A user with a different role -like ROLE_USER- cannot access that page).
However if I include the very same page (XXX.zul) in another page (YYY.zul) by using the <include> tag, the authorization settings for the included page does not work any more (i.e. although a user with the ROLE_USER should not access the page -XXX.zul- he can see it by calling YYY.zul).
I don't know if I could explain it properly.
Thanks
Hi,
I think it will not work with include!!! ZK use event based like desktop not traditional url based like jsp, etc.
Well, let's hear other contribuitors.
Hi Henrichen,
Sorry that I couldn't get what you meant in your previous post.
I have added the INCLUDE dispatcher in my filter configuration but it had no effect.
<filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>INCLUDE</dispatcher> <dispatcher>FORWARD</dispatcher> </filter-mapping>
Check first if the included page request pass thru your filter. Can you "println" something in the filter to prove or disprove it?
If not passed, then we shall check the ZK <include> component. If yes, then it is something more complicated related to ZK + Spring security.
Well, it's not easy to understand for which request it comes to the filter (DelegatingFilterProxy). I could not find a way to say 'OK, now it came to the filter for this included page'. But here's what I did:
I put a breakpoint to the filter and called the page YYY.zul -that includes XXX.zul with an <include> tag (check out my previous post)- for each scenario:
Scenario-1) Filter with no dispatchers defined (only REQUEST by default, I suppose)
<filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
<filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>INCLUDE</dispatcher> </filter-mapping>
I've just come across the same issue in a project created using the zk maven archetype
The defect mentioned above is no longer available (as the zk bug db has been moved), but I can't seem to find a relevant defect in the new system either.
I guess an obvious work-around would be to not embed the content page in another page and include the common headers/footers/sidebars into the main page. But that means lots of copies of the page structure code.
Any other ideas?
Regards, Chris
Asked: 2008-07-30 07:42:07 +0800
Seen: 300 times
Last updated: Oct 05 '14