You might be interested by the way the official demos are handled.

You may notice that all request are HTTP not HTTPS. This is done under the umbrella of the ASF by using a proxy which have the global ASF certificate installed for the OFBiz-VM. So all HTTP and HTTPS traffic come there and is safely redirected as only HTTP traffic to OFBiz which uses the port.https.enabled=N in url.properties

HTH

Jacques

Le 02/10/2014 14:46, Eric Kingston a écrit :
Hi Nicolas,

Thanks for your reply. I'm referring to a hot-deploy component (web application) I built myself. I have an insecure main page that has a link on it that requires authentication to get to the destination page. When I click on that link, because the user is not authenticated, it redirects to a login page, which it should do, but it does it over an insecure connection. The security tag in the request mapping for the link is configured https=false and auth=true, because I don't want the destination page to be presented over a secure connection, but the user must be authenticated to access the page. So, if an unauthenticated user clicks on that link and lands on the login page, that login page is insecure. I too have my login request mapping's security tag's https attribute set to true, so when I click on the link that goes directly to the login page, it is always secure. But, in the instances where the login page is called indirectly for authentication purposes, and is coming from an insecure link/request, the login page is presented insecurely. It seems to me that the security protocol selection in OFBiz is request based, which introduces problems in certain situations where authentication is required, but is coming from an insecure connection. As I mentioned previously, the login page must always be presented over a secure connection. That is why I asked if there was a way to configure the security protocol selection by page instead of request, or even both.

As a side note, I worked on a previous non-OFBiz project that required at least one page (the login page) in a process flow that needed to be presented over a secure connection, but then go to a page that didn't need to be secured. I used Spring's security plugin to accomplish this. The plugin was configured by page. So, basically what I'm looking for is the following flow...

Insecure page with link on that page that requires authentication to go to the destination page -> login page presented over a secure connection -> destination page (after login) that doesn't require a secure connection. So, http -> https (called indirectly, because the following page requires authentication) -> http (doesn't need to be secure, but does require authentication to view). I apparently cannot accomplish this using the OFBiz request mapping features OOTB.

I'm currently investigating whether I can use the Spring security plugin I 
mentioned with OFBiz to accomplish what I'm after.

I hope that clears up any confusion my previous query may have caused.  I look 
forward any suggestions or comments anyone has on this issue.

Thanks.

Eric



On 10/2/2014 1:09 AM, Nicolas Malin wrote:
Hello Eric

Where are you ?

In a specific componant, on local OFBiz or on the demo server ? Because I don't 
reproduce your problem on local, my login page is always secure.

Nicolas
Le 01/10/2014 16:22, Eric Kingston a écrit :
Hi,

Can OFBiz be configured to render the security protocol by page instead of by request? I'm referring to the control flow managed by the controller.xml file in an OFBiz web application. For example.... I have an insecure page that has a link to a page that requires the user to be authenticated. Because the authentication request is coming from an insecure page, the login page, which should always be presented as a secure (https) page, is presented insecurely (http). The login page should *always* be secure. Yet, the way OFBiz handles requests and resulting pages, it isn't. How can I configure OFBiz to set the security protocol by page instead of request? I look forward to any suggestions or comments anyone might have. Thanks.

Sincerely,

Eric




Reply via email to