Hi Eric,
You controller.xml on your component has a inclusion of
common-controller.xml ?
Do you define your own login process on your controller ?
Please try to check with official components like party or accounting.
For the affirmation 'the login page must always be presented over a
secure connection', it's true but what's really a "secure connection" :
https, http over ssh, a closed network ? some possibility for a
different world ;)
Nicolas
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
