[
https://issues.apache.org/jira/browse/OFBIZ-9206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15888142#comment-15888142
]
Jacques Le Roux edited comment on OFBIZ-9206 at 2/28/17 3:40 PM:
-----------------------------------------------------------------
OK I was ready to close this issue with this message
{quote}
Fixed in
trunk r1784549 + r1784555 + r1784558
R16.11 r1784550 + r1784559
R15.11 & 14.11 r1784556+ r1784560
R13.07 r1784745
{quote}
I even wrote that
{quote}
It was an easy fix, I just imported
<SystemProperty systemPropertyId="port.https" systemResourceId="url"
systemPropertyValue=""/>
in trunk demo and all work perfectly.
{quote}
But I missed one point: how deep the ecommerce webapp is entrenched in some
applications components. This can at least be tested with product and catalog
webapp.
# Get to
https://demo-stable.ofbiz.apache.org/catalog/control/EditProduct?productId=GZ-1000
# Click on the "Product Page" button (you may notice an error which has been
"fixed", more a workaround, at OFBIZ-9234)
# Click on the logout link you get to
https://demo-stable.ofbiz.apache.org/ecommerce/control/main but also to blank
page, you just got a 404. The same happens locally, it's not related to demos,
the letsencrypt certificate or the HTTPD frontend config.
If you replace ecommerce/control/main by ecomseo in the URL, it works again.
IIRW this was the initial reason I switched the trunk demo link from the site
home page to ecomseo.
Also if you replace ecommerce by ecomseo in CatalogMenus.xml then all works
really perfectly. What I could do is to make this a parameter, but if you look
for "ecommerce" in applications you find 96 harcoded "ecommerce" strings. Among
the 96 harcoded "ecommerce" strings I could replace those that have a relation
with URLs generation by "ecomseo" and that would be it.
But at this stage I think we need to think more about it. I see 3 alternatives:
# Fixes the underlying problems with ecommerce, good luck while shaving the
yak! See OFBIZ-9234 and OFBIZ-9235 I already crossed while working on the
current issue, for instance.
# My proposition above to replace "ecommerce" strings by "ecomseo". But I know
some are reluctants about that because the ecomseo specifications have not been
defined. Though we also have no specifications for ecommerce, I can understand
this concern. It would be good to have ecomseo specifications defined before
definitely switching to it. I thought about reverting and keep up later. But I
fear it's a risk of loosing momentum and have to do it again if other changes
stack on. I'll rather retroengineer ecomseo to explain what really changes. If
I can't explain all at a functional level, I'll ask Jinghai and especially
Jonathan Schikowski, anyway I already planned to do so.
# This is only related to the logout when coming from catalog/product, and a
simpler way is to remove all ecommerce links from applications. We anyway want
to remove dependencies from plugins in applications. And I believe it's where
we should start.
I'm inclided to the 3rd option, I'll create a thread on dev ML to discuss about
the 3 points above.
In the meantime, I'll now restart the demos and change the link from the site
home page, for at least test and let test.
was (Author: jacques.le.roux):
OK I was ready to close this issue with this message
{quote}
Fixed in
trunk r1784549 + r1784558
R16.11 r1784550 + r1784559
R15.11 & 14.11 r1784556+ r1784560
R13.07 r1784745
{quote}
I even wrote that
{quote}
It was an easy fix, I just imported
<SystemProperty systemPropertyId="port.https" systemResourceId="url"
systemPropertyValue=""/>
in trunk demo and all work perfectly.
{quote}
But I missed one point: how deep the ecommerce webapp is entrenched in some
applications components. This can at least be tested with product and catalog
webapp.
# Get to
https://demo-stable.ofbiz.apache.org/catalog/control/EditProduct?productId=GZ-1000
# Click on the "Product Page" button (you may notice an error which has been
"fixed", more a workaround, at OFBIZ-9234)
# Click on the logout link you get to
https://demo-stable.ofbiz.apache.org/ecommerce/control/main but also to blank
page, you just got a 404. The same happens locally, it's not related to demos,
the letsencrypt certificate or the HTTPD frontend config.
If you replace ecommerce/control/main by ecomseo in the URL, it works again.
IIRW this was the initial reason I switched the trunk demo link from the site
home page to ecomseo.
Also if you replace ecommerce by ecomseo in CatalogMenus.xml then all works
really perfectly. What I could do is to make this a parameter, but if you look
for "ecommerce" in applications you find 96 harcoded "ecommerce" strings. Among
the 96 harcoded "ecommerce" strings I could replace those that have a relation
with URLs generation by "ecomseo" and that would be it.
But at this stage I think we need to think more about it. I see 3 alternatives:
# Fixes the underlying problems with ecommerce, good luck while shaving the
yak! See OFBIZ-9234 and OFBIZ-9235 I already crossed while working on the
current issue, for instance.
# My proposition above to replace "ecommerce" strings by "ecomseo". But I know
some are reluctants about that because the ecomseo specifications have not been
defined. Though we also have no specifications for ecommerce, I can understand
this concern. It would be good to have ecomseo specifications defined before
definitely switching to it. I thought about reverting and keep up later. But I
fear it's a risk of loosing momentum and have to do it again if other changes
stack on. I'll rather retroengineer ecomseo to explain what really changes. If
I can't explain all at a functional level, I'll ask Jinghai and especially
Jonathan Schikowski, anyway I already planned to do so.
# This is only related to the logout when coming from catalog/product, and a
simpler way is to remove all ecommerce links from applications. We anyway want
to remove dependencies from plugins in applications. And I believe it's where
we should start.
I'm inclided to the 3rd option, I'll create a thread on dev ML to discuss about
the 3 points above.
In the meantime, I'll now restart the demos and change the link from the site
home page, for at least test and let test.
> Login and logout process in demos shows a certificate issue
> -----------------------------------------------------------
>
> Key: OFBIZ-9206
> URL: https://issues.apache.org/jira/browse/OFBIZ-9206
> Project: OFBiz
> Issue Type: Bug
> Components: Demo
> Reporter: Jacques Le Roux
> Assignee: Jacques Le Roux
> Priority: Minor
> Attachments: OFBIZ-9206.patch, ofbiz-vm2.apache.org.yaml
>
>
> When, from the site main page http://ofbiz.apache.org/, you get to the demos
> depending on browser (tested on Windows 7) you get some issues:
> * FF
> ** Management Apps: OK
> ** Ecommerce: OK
> * Chrome (Management Apps or Ecommerce)
> ** stable: OK
> ** old: KO - If you copy the URL by hand it works, and after even from the
> main page it works.
> ** trunk: OK
> * IE, same than Chrome
> If, from any browser, you logout from Management Apps you get a certificate
> issue. Actually as we use HSTS the browsers protect us from any 3rd party
> intrusions... Same issue when login in.
> So it seems we have a certificate issue after OFBIZ-7928 and INFRA-11960.
> Maybe it's due to how OFBiz redirects when login in or login out because, so
> far, only the login page is concerned...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
