Who ever it is

Remove me from this ridiculous mail chain.

Sent from my iPhone

> On 02-Oct-2014, at 6:16 pm, Eric Kingston <[email protected]> wrote:
> 
> 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