Interesting post on the Oracle JDeveloper Oracle internal mailing list, answered by Andrew Robinson. Accessing a managed bean in a standard servlet scope like sessionScope or requestScope using the scope as a prefix fails if the bean instance does not exist. Thus, bean reference like #{sessionScope.myBean} may fail while #{myBean} always succeeds. The reason for this is that #{sessionScope….} and #{requestScope…} reference a Map in memory and not the JSF framework.
But why would you want to use the memory scope as a prefix? If you reference an attribute in memory scope, then the search goes from smallest scope to broader scope, which means that if – by accident – there exist two objects with the same name and you wanted to access the object in the broader scope, chances are you access the wrong object. So prefixing the expression puts you on the save side. This however is only good to use when you access objects that already exist in memory (wich could be a previously instantiated managed bean – of course)
Managed beans must be instantiated before they become available in the memory scope, which means they need to be accessed through JSF. Luckily, JSF does not allow to configure two managed beans with the same name in different scopes. So even without a scope prefix, there is no risk that application code accidentally accesses the wrong object.
Note however that using ADFc specific scope like viewScope and pageFlowScope, a prefix of “pageFlowScope” or “viewScope” is required in the EL reference.
Frank
A great discussion on the JDeveloper forum on OTN brough a new addition to ADF application security that I like to share.
Chapter 30 of the Oracle® Fusion Middleware Fusion Developer’s Guide for Oracle Application Development Framework 11g Release 1 explains the JAAS protection mechanism for ADF pages and Task Flows. In here it is recommended that you reduce the number of JSF pages in the adfc-config.xml file to the absolute minimum and only give ADF Security permissions to those documents that need to be accessible from a browser request.
All other pages should be located in bounded task flows, which you can protect declaratively against GET requests, as they are issued from a browser URL. Bounded task flows need to be ganted to users through application roles to be accessible.
The discussion on OTN is about protecting the phyical JSPX files. If you are an authenticated and authorized user, then you could directly access the JSPX page, e.g. calling localhost:7101/myapp/faces/Departments.jspx. This then serves the page – though it may not be fully functional because it is not launched within the controller context.
The recommendation therefore is to store JSPX documents under the WEB-INF directory of the public_html folder. This solves the problem of users accessing physical files directly
Frank
Ps.: Note that if moving JSPX documents into the WEB-INF folder is not an option for you, you can write a servlet filter that checks the incoming request URL for the resource it accesses. If a jspx file is accessed you would return a http 403 error.
Our ADF Faces documentation contains little nuggets of poetry and wisdom that are easy to memorize helping you to better understand the product – and answer questions on OTN with it. For example, today I found and liked:
Note: If your trigger component is an inputLov or an inputComboBoxLov, and the target component is an input component set to required, then a validation error will be thrown for the input component when the LOV popup is displayed. To avoid this, you must use programmatic partial page rendering.
Note: In some cases, you may want a component to be rerendered only when a particular event is fired, not for every event associated with the trigger component, or you may want some logic to determine whether a component is to be rerendered. In these cases, you can programatically enable PPR.
Excellent !
Frank
Want to dig your own nuggets? here is the documentation: Looking forward to read your blogs and tweets with your favorite quotes.
RSS
Email