I have a CDIView within my application. It’s annotated with
@RolesAllowed({"Bearbeiter", "Betrachter"})
so only those two groups are allowed to access the view. According to the Wildfly 8 - Log, the check seems to work correctly:
[code]
23:06:37,456 INFO [com.vaadin.cdi.CDIViewProvider]
(default task-17) Checking if user admin@studi is having access to Managed Bean [class fhdortmund.seelab.studimanager.views.CompaniesView]
with qualifiers [@Any@Default]
: false
23:06:37,456 INFO [com.vaadin.cdi.access.JaasAccessControl]
(default task-17) Getting request com.vaadin.server.VaadinServletRequest@4eb950c0
23:06:37,456 INFO [com.vaadin.cdi.CDIViewProvider]
(default task-17) User admin@studi did not have access to view "Managed Bean [class fhdortmund.seelab.studimanager.views.CompaniesView]
with qualifiers [@Any@Default]
"
23:06:37,457 INFO [com.vaadin.cdi.access.JaasAccessControl]
(default task-17) Getting request com.vaadin.server.VaadinServletRequest@4eb950c0
23:06:37,458 INFO [com.vaadin.cdi.access.JaasAccessControl]
(default task-17) Getting request com.vaadin.server.VaadinServletRequest@4eb950c0
[/code]However, logging in with the user “admin@studi”(not member of one of the upper roles) simply results in a forward to the view (using the navigator). I can see everything of generated and rendered HTML-Code.
Yes, definitely you should add the error view if you are using @Roles annotation. Too bad it still has
a major limitation , you just have to guess that it was due to inadequate access.
You could extend CDIViewProvider and override / reimplement getViewName and getView to always return your ViewName / View , and instead register a ViewChangeEvent with the Navigator that does a check like CDIViewProvider.isUserHavingAccessToView() , return false and do a Notification when the user does not have access to a view.
Unfortunately, this is the only way to at least restrict the access to different views within my application. Thanks for your response, Petrus.
If one of the persons in charge of the CDI Addon wants to evaluate my issue, I’m willing to detail my problems here, because I think it’s a bug I’m facing here.
Errm , I dont quite follow.
I’ll refrase my previous comment. You can definitly (and easily ) create your own custom CDIViewProvider,
My previous comment was related to the issue tha Matti pointed out, that the current implementation handles no-access to a view the same as a non existing view. aka you dont know why you could not navigate to the view, and this is not good user experience.
My suggestion would still deny the user access to that view, via the ViewChangeEvent, just that now you can inform the end user that (s)he does not have access to the given view…
But perhap we did not understand you correctly , are you saying that the user is still given access to the view even if (s)he should have been denied ? If that is the case you are probably adding the views to the Navigator manually and then it will automatically add other view providers to the Navigator. If you use CDI you should NOT add any views to the Navigator manually. This might also explain why you are seeing the logs that the user does not have access to the view but still navigate to it…
Well it is a combination of CDIViewProvider and BeanManager, The CDIViewProvider uses the BeanManager to get a list of all the classes / beans in your classpath that implements View and have the @CDIView annotation, from the CDIView annotation’s value property it will figure out what the name/ URIFragment is for the view, and this is why you no longer need to add these Views to the Navigator…
The BeanManager will manage the lifecycle for the view Beans, aka create instance if needed , CDI injection, etc…
I heard that somebody is finally working on this from our R&D. So no is the time to go to http://dev.vaadin.com/ticket/13566 and “vote for it”. Cc or leave comment, or if you have gold support, do the real feature vote.
Added comment and small patch ( to demonstrate one way of handling it )
It should be backwards compatible , but the default Navigator will now encounter a SecurityException if a user does not have access to a view. Provided a CDINavigator with listeners in the event of a SecurityException…
