Orbeon Form - Is there anyway to disallow download attachment by default? - orbeon

I found a useful document about it: https://doc.orbeon.com/form-runner/component/attachment
Therefore I did a similar approach, I added this line in properties-local.xml:
<property as="xs:string" name="oxg.xforms.xbl.fr.attachment.allow-download" value="false"/>
but it doesn't work. When I created Form Builder and added attachment, the setting still marked allow download.

I think that you just have a typo. Try the following (with the property name starting with oxf instead of org). I've tried this locally and it is working for me.
<property
as="xs:string"
name="oxf.xforms.xbl.fr.attachment.allow-download"
value="false"/>

Related

Path based vulnerability in Spring hybris

We have got path based vulnerability issues in Qualys report. I have gone through stackoverflow questions like this one and configured useDefaultSuffixPattern as false as shown below.
I am still able to load the page with /about.anything even though in controller I have given as #RequestMapping(value = "/about")
Is there any other configuration we need to update to stop this from happening?
<bean
class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
<property name="order" value="0" />
<!-- Set whether to register paths using the default suffix pattern as
well: i.e. whether "/users" should be registered as "/users.*" and "/users/"
too. Default is "true". Turn this convention off if you intend to interpret
your #RequestMapping paths strictly. Note that paths which include a ".xxx"
suffix or end with "/" already will not be transformed using the default
suffix pattern in any case. -->
<property name="useDefaultSuffixPattern" value="false" />
<property name="pathMatcher" ref="pathMatcher" />
</bean>
We are using hybris 1811 version
This might be happening because of an inherent bug in Spring where it ignores everything after the dot(.) in the URL.
To resolve this you must create the path variable pattern for GET call in your controller more rigid.

Trying to get form data as XML via REST API

It should be a simple thing and it probably is, but I'm not achieving to get the XML data of a draft form via the REST API described in the Orbeon docs.
I did the following changes to the properties-local-dev.xml file:
<property
as="xs:string"
processor-name="oxf:page-flow"
name="page-public-methods"
value="GET HEAD POST"/>
<property
as="xs:string"
processor-name="oxf:page-flow"
name="service-public-methods"
value="GET HEAD"/>
<property
as="xs:anyURI"
name="oxf.fr.persistence.exist.exist-uri"
value="/exist/rest/db/orbeon/fr"/>
<page public-methods="GET HEAD POST" view="view.xpl"/>
<service public-methods="GET HEAD" view="view.xpl"/>
Then I tried different URL's to call the data:
http://localhost:9090/orbeon/exist/rest/db/orbeon/fr/gsmn/hello-world/draft/f025a471b2c8452dd65267cc5886063d995757f5/data.xml
http://localhost:9090/orbeon/crud/gsmn/hello-world/draft/f025a471b2c8452dd65267cc5886063d995757f5/data.xml
http://localhost:9090/orbeon/fr/service/persistence/crud/gsmn/hello-world/draft/f025a471b2c8452dd65267cc5886063d995757f5/data.xml
Form Runner resides on :
http://localhost:9090/orbeon/fr/
Is there something obvious I'm missing?
Thanks
Noel
Assuming your app name is gsmn and your form name is hello-world, then the last URL you mentioned (copied below for clarity), should work.
http://localhost:9090/orbeon/fr/service/persistence/crud/gsmn/hello-world/draft/92aad35a44876b3bfac3b4d6f835130fbd1fe19e/data.xml
However, most likely, the issue is that you're trying this with eXist, and that, as of this writing, the autosave functionality isn't supported by Orbeon Forms on eXist; it is only supported on relational databases. For more on this, see the support matrix for different databases, and the RFE to add support for autosave on eXist.

Orbeon forms builder with MS SQL

I lose all form data and get an error saying error performing search when I set the following property in Orbeon Form Builder properties - local.xml file
<property as="xs:string" name="oxf.fr.persistence.provider.*.*.*" value="sqlserver"/>
Can someone please help me?

Orbeon: success uri configuration

I want to set success uri to Another Orbeon form.
Example:
After clicking on Workflow send Button, it should redirects to new Orbeon form
I have tried with
<property as="xs:anyURI" name="oxf.fr.detail.send.success.uri.*.*"
value="/fr/MY-app-name/My-form-name/new"/>
It seems it is calling this page after clicking send button, but it is Not showing any control of this form
I have also set this property:
<property
as="xs:boolean"
name="oxf.fr.detail.send.success.prune.*.*"
value="false"/>

Spring security - how to mention both form based and basic authentication

Is it possible to mention both form-based and basic authentication in Spring security using namespace configuration without overriding other ? So that the appliciation could serve both browser based request and remoting client.
The response by #grimesjm is right. However, if you are using Spring 3.x you have to adapt the class names to:
<bean id="basicProcessingFilter" class="org.springframework.security.web.authentication.www.BasicAuthenticationFilter">
<property name="authenticationManager">
<ref bean="authenticationManager" />
</property>
<property name="authenticationEntryPoint">
<ref bean="authenticationEntryPoint" />
</property>
</bean>
<bean id="authenticationEntryPoint"
class="org.springframework.security.web.authentication.www.BasicAuthenticationEntryPoint">
<property name="realmName" value="Your realm here" />
</bean>
And
<sec:http auto-config="true">
... your intercept-url here
<sec:custom-filter before="SECURITY_CONTEXT_FILTER" ref="basicProcessingFilter" />
<sec:form-login ... />
....
</sec:http>
I do not know whether placing the filter before SECURITY_CONTEXT_FILTER is the best option or not.
The end result you want is possible, I have ran into that exact same problem and here is my solution.
Anytime when defining form-login in the namespace it will override automatically any other authentication filters you apply via namespace. This is done through the ordering of the filter chain look at FilterChainOrder.java in the spring security to see how the order is actually applied to each filter.
To get around this remove the http-basic tag from the namespace then manually define the bean to handle basic authentication and place its order before the AuthenticationProcessingFilter because this is the spring security filter that will handle the form-login.
The BasicProcessingFilter spring provides to handle Basic authentication is a passive filter, meaning that if the credentials are missing it will continue down the filter chain until it finds the appropriate filter to handle the request.
Now by manually defining the BasicProcessingFilter bean we can set the order that it will appear in the filter chain.
Below is an example of the additional xml declarations you will need to supply in the security xml (Spring Security < 3.x)
<bean id="basicProcessingFilter" class="org.springframework.security.ui.basicauth.BasicProcessingFilter">
<property name="authenticationManager"><ref bean="authenticationManager"/></property>
<security:custom-filter before="AUTHENTICATION_PROCESSING_FILTER"/>
<property name="authenticationEntryPoint"><ref bean="authenticationEntryPoint"/></property>
</bean>
<bean id="authenticationEntryPoint"
class="org.springframework.security.ui.basicauth.BasicProcessingFilterEntryPoint">
<property name="realmName" value="My Realm Here"/>
</bean>
Also note if your authenticationManager reference isn't found you can add an alias to your namespace like the one below.
<security:authentication-manager alias="authenticationManager"/>
The end result is the basic filter will be applied as a passive filter and if its required credentials are missing it will continue down the filter chain and the form-login filter will then handle it.
The problem with this approach is that if credentials are correctly entered, the response back is the login page from the form-login filter.
However, It appears that this problem will be fixed by spring in version 3.1 of spring security and this work around will no longer be needed.
It is now possible with Spring Security 3.1.0
It seems that it is not possible to declare both form and basic authentication using namespace configuration.
A reference link to spring community :
http://forum.springsource.org/showthread.php?t=72724&highlight=form+basic+authentication

Resources