Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-9206

Login and logout process in demo backends (Management Apps) shows a certificate issue

    Details

      Description

      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...

      1. access_log-trunk.txt
        73 kB
        Jacques Le Roux
      2. console.log-trunk.txt.zip
        365 kB
        Jacques Le Roux
      3. OFBIZ-9206.patch
        6 kB
        Jacques Le Roux
      4. ofbiz-vm2.apache.org.yaml
        6 kB
        Jacques Le Roux

        Issue Links

          Activity

          Hide
          pfm.smits Pierre Smits added a comment -

          The issue occurs after the login and logout process has been invoked/executed.

          Steps to reproduce the login issue:

          1. go to https://demo-trunk.ofbiz.apache.org/catalog
          2. provide login details - userId: admin, password: ofbiz

          Steps to reproduce the logout issue:

          1. access the demo via http://demo-old.ofbiz.apache.org/catalog/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
          2. log out from the application via the 'logout' button/function
          Show
          pfm.smits Pierre Smits added a comment - The issue occurs after the login and logout process has been invoked/executed. Steps to reproduce the login issue: go to https://demo-trunk.ofbiz.apache.org/catalog provide login details - userId: admin, password: ofbiz Steps to reproduce the logout issue: access the demo via http://demo-old.ofbiz.apache.org/catalog/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y log out from the application via the 'logout' button/function
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          We crossed on wire Pierre, your summary is better, put back

          Show
          jacques.le.roux Jacques Le Roux added a comment - We crossed on wire Pierre, your summary is better, put back
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Not only Login and logout process have issues but also all webtools links, for all demos versions.

          Steps to reproduce:

          1. go to https://demo-trunk.ofbiz.apache.org/catalog
          2. provide login details - userId: admin, password: ofbiz
          3. get to webtools using the applications menu (depends on theme). All links in the page have the 8443 port concatenated to the domain, it should not

          I reverted r1781842 at r1782432 (back to VM direct access)

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Not only Login and logout process have issues but also all webtools links, for all demos versions. Steps to reproduce: go to https://demo-trunk.ofbiz.apache.org/catalog provide login details - userId: admin, password: ofbiz get to webtools using the applications menu (depends on theme). All links in the page have the 8443 port concatenated to the domain, it should not I reverted r1781842 at r1782432 (back to VM direct access)
          Hide
          mbrohl Michael Brohl added a comment -

          The current state prevents Firefox users from accessing the site. After login, the certificate warning page is displayed, stating that the application uses HTTP Strict Transport Security (HSTS) and does not allow to enter an exception to show the page regardless of the false certificate informations.

          I know nothing about the specific configurations of the ASF server but it's a fairly common use case to have several OFBiz instances running on different ports mapped against different subdomains using SSL certificates.

          Can you explain what makes our configuration special?

          I propose to remove the demo links from our website as long as we have these problems because I think it puts the project in a bad light.

          Show
          mbrohl Michael Brohl added a comment - The current state prevents Firefox users from accessing the site. After login, the certificate warning page is displayed, stating that the application uses HTTP Strict Transport Security (HSTS) and does not allow to enter an exception to show the page regardless of the false certificate informations. I know nothing about the specific configurations of the ASF server but it's a fairly common use case to have several OFBiz instances running on different ports mapped against different subdomains using SSL certificates. Can you explain what makes our configuration special? I propose to remove the demo links from our website as long as we have these problems because I think it puts the project in a bad light.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi Michael, it's somehow explained at INFRA-11960.

          For your proposition about removing the links it would be better to ask opinions on the dev ML.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi Michael, it's somehow explained at INFRA-11960 . For your proposition about removing the links it would be better to ask opinions on the dev ML.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          BTW I just reopened OFBIZ-7928 which is related

          Show
          jacques.le.roux Jacques Le Roux added a comment - BTW I just reopened OFBIZ-7928 which is related
          Show
          jacques.le.roux Jacques Le Roux added a comment - I started with https://github.com/apache/infrastructure-puppet/pull/181
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          OK, it was an easy fix, I just imported

          <SystemProperty systemPropertyId="port.https" systemResourceId="url" systemPropertyValue=""/>

          in trunk demo and all work perfectly.

          I also tried to replace locally
          port.https=8443
          by
          port.https=
          in url.properties (w/o SystemProperty) and did not face any issue but with portOffset. This is due to the WebSiteProperties class works and there is also an easy fix: don't add twice the portOffset when it's build from the request, and only then. Keep it as is when it's build from a WebSite GenericValue. We then trust the user and don't rely on the request.

          I attach a patch for your tests before I commit and backport and change the demo links.

          In this patch I also removed the deprecated RequestHandler.getDefaultServerRootUrl() I think it was time...

          Show
          jacques.le.roux Jacques Le Roux added a comment - OK, it was an easy fix, I just imported <SystemProperty systemPropertyId="port.https" systemResourceId="url" systemPropertyValue=""/> in trunk demo and all work perfectly. I also tried to replace locally port.https=8443 by port.https= in url.properties (w/o SystemProperty) and did not face any issue but with portOffset. This is due to the WebSiteProperties class works and there is also an easy fix: don't add twice the portOffset when it's build from the request, and only then. Keep it as is when it's build from a WebSite GenericValue. We then trust the user and don't rely on the request. I attach a patch for your tests before I commit and backport and change the demo links. In this patch I also removed the deprecated RequestHandler.getDefaultServerRootUrl() I think it was time...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Of course, for a site not protected by a certificate (like when developing with localhost) and because if port.https is empty we rely on the port in the 1st request sent, you need to put the correct port when login in, something like https://localhost:8443/catalog/control/login. Then all follow...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Of course, for a site not protected by a certificate (like when developing with localhost) and because if port.https is empty we rely on the port in the 1st request sent, you need to put the correct port when login in, something like https://localhost:8443/catalog/control/login . Then all follow...
          Hide
          leonardlin Leonard Lin added a comment - - edited

          Hi Jacques Le Roux , thanks for working on this.

          I applied your patch.
          added the " <SystemProperty systemPropertyId="port.https" systemResourceId="url" systemPropertyValue=""/>"
          into the table.

          Login mask now still shows the hostname:port in the urls.

          I'm not quiet sure if I follow the discussion above.
          What's the intended behaviour?
          In which cases should it show the full hostname+port and in which cases it should not?

          Based on looking at it, for me it would make sense that it should never generate the full hostname:port url, unless it's explicitly set in the url.properties / SystemProperty table.
          But I'm not sure if I understand all the cases/scenarious

          Best
          Leo

          <div class="screenlet-body">
                <form method="post" action="https://localhost:8443/catalog/control/login" name="loginform">
                  <table class="basic-table" cellspacing="0">
                    <tr>
                      <td class="label">User Name</td>
                      <td><input type="text" name="USERNAME" value="" size="20"/></td>
                    </tr>
                    <tr>
                      <td class="label">Password</td>
                      <td><input type="password" name="PASSWORD" value="" size="20"/></td>
                    </tr>
                    <tr>
                      <td colspan="2" align="center">
                        <input type="submit" value="Login"/>
                      </td>
                    </tr>
                  </table>
                  <input type="hidden" name="JavaScriptEnabled" value="N"/>
                  <br />
                  <a href="https://localhost:8443/catalog/control/forgotPassword_step1">Forgot Your Password?</a>
                </form>
              </div>
              
          Show
          leonardlin Leonard Lin added a comment - - edited Hi Jacques Le Roux , thanks for working on this. I applied your patch. added the " <SystemProperty systemPropertyId="port.https" systemResourceId="url" systemPropertyValue=""/>" into the table. Login mask now still shows the hostname:port in the urls. I'm not quiet sure if I follow the discussion above. What's the intended behaviour? In which cases should it show the full hostname+port and in which cases it should not? Based on looking at it, for me it would make sense that it should never generate the full hostname:port url, unless it's explicitly set in the url.properties / SystemProperty table. But I'm not sure if I understand all the cases/scenarious Best Leo <div class= "screenlet-body" > <form method= "post" action= "https: //localhost:8443/catalog/control/login" name= "loginform" > <table class= "basic-table" cellspacing= "0" > <tr> <td class= "label" >User Name</td> <td><input type= "text" name= "USERNAME" value= "" size=" 20"/></td> </tr> <tr> <td class= "label" >Password</td> <td><input type= "password" name= "PASSWORD" value= "" size=" 20"/></td> </tr> <tr> <td colspan= "2" align= "center" > <input type= "submit" value= "Login" /> </td> </tr> </table> <input type= "hidden" name= "JavaScriptEnabled" value= "N" /> <br /> <a href= "https: //localhost:8443/catalog/control/forgotPassword_step1" >Forgot Your Password?</a> </form> </div>
          Hide
          leonardlin Leonard Lin added a comment -

          Jacques Le Roux ah wait, I just read through your fix and let me redeploy behind a reverse proxy and try again.
          sorry my bad

          Show
          leonardlin Leonard Lin added a comment - Jacques Le Roux ah wait, I just read through your fix and let me redeploy behind a reverse proxy and try again. sorry my bad
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Thanks Leonard,

          Actually I asked you to test in OFBIZ-9224 because I thought it's maybe related but it could be it's not and then better to report your tries there.

          Ah, and also the SystemProperty was only to confirm my idea on demo before working to find a defintive solution, which is finally the patch.
          Since the demos rebuild from scratch every UTC morning the SystemProperty is no longer there anymore but everybody can still test the same and confirm the issue is not with the new certificate config (done through Puppet).

          Here is for instance the config for the trunk

          # ************************************
          # Vhost template in module puppetlabs-apache
          # Managed by Puppet
          # ************************************
          
          <VirtualHost demo-trunk.ofbiz.apache.org:443>
            ServerName demo-trunk.ofbiz.apache.org
          
            ## Vhost docroot
            DocumentRoot "/var/www/ofbiz/big-files"
          
            ## Directories, there should at least be a declaration for /var/www/ofbiz/big-files
          
            <Directory "/var/www/ofbiz/big-files">
              Options Indexes FollowSymLinks MultiViews
              AllowOverride None
              Require all granted
            </Directory>
          
            ## Logging
            ErrorLog "/var/log/apache2/ofbiz-ssl-trunk_error.log"
            ServerSignature Off
            CustomLog "/var/log/apache2/ofbiz-ssl-trunk.apache.org.http_access.log" combined
          
            ## SSL directives
            SSLEngine on
            SSLCertificateFile      "/etc/letsencrypt/live/ofbiz-vm2.apache.org/cert.pem"
            SSLCertificateKeyFile   "/etc/letsencrypt/live/ofbiz-vm2.apache.org/privkey.pem"
            SSLCertificateChainFile "/etc/letsencrypt/live/ofbiz-vm2.apache.org/chain.pem"
            SSLCACertificatePath    "/etc/ssl/certs"
          
            ## Custom fragment
            ProxyRequests Off
          ProxyPreserveHost On
          ProxyPass / ajp://localhost:8009/
          ProxyPassReverse / ajp://localhost:8009/
          
          </VirtualHost>
          

          We have also stable and old alike, bigfiles is used to serve static videos from https://cwiki.apache.org/confluence/display/OFBIZ/Framework+Introduction+Videos+and+Diagrams

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Thanks Leonard, Actually I asked you to test in OFBIZ-9224 because I thought it's maybe related but it could be it's not and then better to report your tries there. Ah, and also the SystemProperty was only to confirm my idea on demo before working to find a defintive solution, which is finally the patch. Since the demos rebuild from scratch every UTC morning the SystemProperty is no longer there anymore but everybody can still test the same and confirm the issue is not with the new certificate config (done through Puppet). Here is for instance the config for the trunk # ************************************ # Vhost template in module puppetlabs-apache # Managed by Puppet # ************************************ <VirtualHost demo-trunk.ofbiz.apache.org:443> ServerName demo-trunk.ofbiz.apache.org ## Vhost docroot DocumentRoot "/ var /www/ofbiz/big-files" ## Directories, there should at least be a declaration for / var /www/ofbiz/big-files <Directory "/ var /www/ofbiz/big-files" > Options Indexes FollowSymLinks MultiViews AllowOverride None Require all granted </Directory> ## Logging ErrorLog "/ var /log/apache2/ofbiz-ssl-trunk_error.log" ServerSignature Off CustomLog "/ var /log/apache2/ofbiz-ssl-trunk.apache.org.http_access.log" combined ## SSL directives SSLEngine on SSLCertificateFile "/etc/letsencrypt/live/ofbiz-vm2.apache.org/cert.pem" SSLCertificateKeyFile "/etc/letsencrypt/live/ofbiz-vm2.apache.org/privkey.pem" SSLCertificateChainFile "/etc/letsencrypt/live/ofbiz-vm2.apache.org/chain.pem" SSLCACertificatePath "/etc/ssl/certs" ## Custom fragment ProxyRequests Off ProxyPreserveHost On ProxyPass / ajp: //localhost:8009/ ProxyPassReverse / ajp: //localhost:8009/ </VirtualHost> We have also stable and old alike, bigfiles is used to serve static videos from https://cwiki.apache.org/confluence/display/OFBIZ/Framework+Introduction+Videos+and+Diagrams
          Hide
          leonardlin Leonard Lin added a comment -

          Hi Jacques Le Roux

          I tested the patch with a load balancer and it worked for me.

          load balancer listens to https:443
          ofbiz internally runs on https:8443

          The links generated are https://hostname:443/url

          I didn't even add the SystemProperty entry
          The only comment I would have is that the port-number 443 is not needed for protocol https

          <form method="post" action="https://hostname:443/catalog/control/login" name="loginform">

          but it works

          Show
          leonardlin Leonard Lin added a comment - Hi Jacques Le Roux I tested the patch with a load balancer and it worked for me. load balancer listens to https:443 ofbiz internally runs on https:8443 The links generated are https://hostname:443/url I didn't even add the SystemProperty entry The only comment I would have is that the port-number 443 is not needed for protocol https <form method="post" action="https://hostname:443/catalog/control/login" name="loginform"> but it works
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi Leonard,

          I didn't even add the SystemProperty entry

          Yes, as explained above it was only needed for my early tests on OFBiz demos. I'll commit the patch rather.

          The only comment I would have is that the port-number 443 is not needed for protocol https

          Actually there is 2 aspects:

          1. when working locally (locahost) w/o a certificate you need a port, by default it's 8443.
          2. when using a server and a frontend w/ (or I guess rarely w/o) a certificate you define a port, by default it's 443.
            In either cases, when you login, the URL you use defines which port will be used by OFBiz internally. Because OFBiz picks this port and, if it works, keeps it as reference for creating new URLs.

          For instance the trunk demo uses 8443 (see attached ofbiz-vm2.apache.org.yaml for completeness)
          So when you type demo-trunk.ofbiz.apache.org you actually send it to demo-trunk.ofbiz.apache.org:443 wich is finally sent to OFBiz as ofbiz-vm2.apache.org:8443 through AJP.

          Note that since OFBIZ-6849 we use only HTTPS in OFBiz and it's enforced by a HSTS header.
          Note also that you can offset the port (all ports actually) using the portoffset feature. This is done with demos and for instance the stable demo responds on 18443 (or 18080 but hen HSTS forces to 18443) and old on 28443.

          Thanks for your feeback, it confirms that I can now switch the demos to the demo-*.ofbiz.apache.org URLs

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi Leonard, I didn't even add the SystemProperty entry Yes, as explained above it was only needed for my early tests on OFBiz demos. I'll commit the patch rather. The only comment I would have is that the port-number 443 is not needed for protocol https Actually there is 2 aspects: when working locally (locahost) w/o a certificate you need a port, by default it's 8443. when using a server and a frontend w/ (or I guess rarely w/o) a certificate you define a port, by default it's 443. In either cases, when you login, the URL you use defines which port will be used by OFBiz internally. Because OFBiz picks this port and, if it works, keeps it as reference for creating new URLs. For instance the trunk demo uses 8443 (see attached ofbiz-vm2.apache.org.yaml for completeness) So when you type demo-trunk.ofbiz.apache.org you actually send it to demo-trunk.ofbiz.apache.org:443 wich is finally sent to OFBiz as ofbiz-vm2.apache.org:8443 through AJP. Note that since OFBIZ-6849 we use only HTTPS in OFBiz and it's enforced by a HSTS header. Note also that you can offset the port (all ports actually) using the portoffset feature. This is done with demos and for instance the stable demo responds on 18443 (or 18080 but hen HSTS forces to 18443) and old on 28443. Thanks for your feeback, it confirms that I can now switch the demos to the demo-*.ofbiz.apache.org URLs
          Hide
          pfm.smits Pierre Smits added a comment - - edited

          When you look at the proxy settings in Apache Httpd for the various demo sites, you'll see that they don't utilise the http(s) protocol of/for OFBiz, but the AJP protocol.

          Show
          pfm.smits Pierre Smits added a comment - - edited When you look at the proxy settings in Apache Httpd for the various demo sites, you'll see that they don't utilise the http(s) protocol of/for OFBiz, but the AJP protocol.
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          OK I was ready to close this issue with this message

          Fixed in
          trunk r1784549 + r1784555 + r1784558
          R16.11 r1784550 + r1784559
          R15.11 & 14.11 r1784556+ r1784560
          R13.07 r1784745

          I even wrote that

          It was an easy fix, I just imported
          <SystemProperty systemPropertyId="port.https" systemResourceId="url" systemPropertyValue=""/>
          in trunk demo and all work perfectly.

          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.

          1. Get to https://demo-stable.ofbiz.apache.org/catalog/control/EditProduct?productId=GZ-1000
          2. Click on the "Product Page" button (you may notice an error which has been "fixed", more a workaround, at OFBIZ-9234)
          3. 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:

          1. 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.
          2. 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.
          3. 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.

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited OK I was ready to close this issue with this message Fixed in trunk r1784549 + r1784555 + r1784558 R16.11 r1784550 + r1784559 R15.11 & 14.11 r1784556+ r1784560 R13.07 r1784745 I even wrote that It was an easy fix, I just imported <SystemProperty systemPropertyId="port.https" systemResourceId="url" systemPropertyValue=""/> in trunk demo and all work perfectly. 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.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I'll also check the situation regarding http://svn.apache.org/viewvc?view=revision&revision=1745732

          Show
          jacques.le.roux Jacques Le Roux added a comment - I'll also check the situation regarding http://svn.apache.org/viewvc?view=revision&revision=1745732
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          On demos the same problem exists on the ecommerce side (w/o passing by the backend, catalog/product)

          • Stable a trunk
            When you login in ecommerce it's generates this URL https://demo-stable.ofbiz.apache.org/ecommerce/control/checkLogin/main and a blank page (actually a 404, you see it with ecomseo and in trunk which uses ecomseo by default), but if you update (F5) the page it works, same for logout.
          • old same kind of issue but generates a SSL_ERROR_RX_RECORD_TOO_LONG

          I revert all and will see later...

          Show
          jacques.le.roux Jacques Le Roux added a comment - On demos the same problem exists on the ecommerce side (w/o passing by the backend, catalog/product) Stable a trunk When you login in ecommerce it's generates this URL https://demo-stable.ofbiz.apache.org/ecommerce/control/checkLogin/main and a blank page (actually a 404, you see it with ecomseo and in trunk which uses ecomseo by default), but if you update (F5) the page it works, same for logout. old same kind of issue but generates a SSL_ERROR_RX_RECORD_TOO_LONG I revert all and will see later...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Reverted at
          trunk r1784760
          R16.11 r1784762
          R14.12, 15.12 r1784766
          R13.07 r1784771

          Actually found the same problem exists after reverting and with no certificate links (direct to vm2) but in old. I will check that again...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Reverted at trunk r1784760 R16.11 r1784762 R14.12, 15.12 r1784766 R13.07 r1784771 Actually found the same problem exists after reverting and with no certificate links (direct to vm2) but in old. I will check that again...
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Because of my conclusions at OFBIZ-9240 I'll reapply the changes and will test on demos.

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Because of my conclusions at OFBIZ-9240 I'll reapply the changes and will test on demos.
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Fixed in trunk at r1784930.

          But this is very dissapointing because unlike locally (cf OFBIZ-9240) login out shows a 404 page with ecomseo and a blank page for ecommerce.

          It's even incomprehensible for me so far. For instance have a look at those simplified snippets from access and console logs:

          [01/Mar/2017:15:23:55 +0000] "GET /ecomseo/ HTTP/1.1" 200 105021 "-"
          [01/Mar/2017:15:23:56 +0000] "GET /content/contentForum.css HTTP/1.1" 302 - "https://demo-trunk.ofbiz.apache.org/ecomseo/additem"
          [01/Mar/2017:15:23:56 +0000] "POST /ecomseo/additem HTTP/1.1" 200 111589 "https://demo-trunk.ofbiz.apache.org/ecomseo/"
          [01/Mar/2017:15:23:56 +0000] "GET /content/control/main HTTP/1.1" 200 8946 "https://demo-trunk.ofbiz.apache.org/ecomseo/additem"
          [01/Mar/2017:15:23:58 +0000] "GET /ecomseo/quickcheckout HTTP/1.1" 200 10396 "https://demo-trunk.ofbiz.apache.org/ecomseo/additem"
          [01/Mar/2017:15:23:58 +0000] "GET /content/contentForum.css HTTP/1.1" 302 - "https://demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout"
          [01/Mar/2017:15:23:58 +0000] "GET /content/control/main HTTP/1.1" 200 8946 "https://demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout"
          [01/Mar/2017:15:24:05 +0000] "POST /ecomseo/login HTTP/1.1" 302 - "https://demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout"
          [01/Mar/2017:15:24:05 +0000] "GET /ecomseo/quickcheckout HTTP/1.1" 200 28992 "https://demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout"
          [01/Mar/2017:15:24:05 +0000] "GET /content/contentForum.css HTTP/1.1" 302 - "https://demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout"
          [01/Mar/2017:15:24:05 +0000] "GET /content/control/main HTTP/1.1" 200 8946 "https://demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout"
          [01/Mar/2017:15:24:12 +0000] "GET /ecomseo/logout HTTP/1.1" 302 - "https://demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout"
          [01/Mar/2017:15:24:12 +0000] "GET /ecomseo/ HTTP/1.1" 404 236 "https://demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout"
          
          2017-03-01 15:23:55,147 |ajp-nio-8009-exec-1  |ControlServlet                |T| [[[main(Domain:https://demo-trunk.ofbiz.apache.org)] Request Done- total:1.671,since last([main(Domain:http...):1.671]]
          2017-03-01 15:23:55,147 |ajp-nio-8009-exec-1  |SeoContextFilter              |W| [Filtered request]: /ecomseo/
          2017-03-01 15:23:55,592 |http-nio-8443-exec-8 |ControlEventListener          |I| Creating session:  hidden sessionId by default.
          2017-03-01 15:23:55,592 |http-nio-8443-exec-8 |ControlServlet                |T| [[[setSessionTimeZone(Domain:https://demo-trunk-ofbiz.apache.org)] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
          [...]
          2017-03-01 15:24:12,759 |ajp-nio-8009-exec-8  |ControlServlet                |T| [[[logout(Domain:https://demo-trunk.ofbiz.apache.org)] Request Done- total:0.021,since last([logout(Domain:ht...):0.021]]
          2017-03-01 15:24:12,834 |ajp-nio-8009-exec-10 |SeoContextFilter              |I| Can NOT forward this url: /ecomseo/
          

          Have a look at console.log-trunk.txt.zip and access_log-trunk.txt for more.

          Anyway this should not block us to use a certificate for at least trunk and stable as a start.
          So I'll also commit stable and will work on OFBIZ-9240 locally to try to understand they underlying reason which seems to lay in SeoContextFilter class. I have tried to tweak SeoConfig.xml w/o results.

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Fixed in trunk at r1784930. But this is very dissapointing because unlike locally (cf OFBIZ-9240 ) login out shows a 404 page with ecomseo and a blank page for ecommerce. It's even incomprehensible for me so far. For instance have a look at those simplified snippets from access and console logs: [01/Mar/2017:15:23:55 +0000] "GET /ecomseo/ HTTP/1.1" 200 105021 "-" [01/Mar/2017:15:23:56 +0000] "GET /content/contentForum.css HTTP/1.1" 302 - "https: //demo-trunk.ofbiz.apache.org/ecomseo/additem" [01/Mar/2017:15:23:56 +0000] "POST /ecomseo/additem HTTP/1.1" 200 111589 "https: //demo-trunk.ofbiz.apache.org/ecomseo/" [01/Mar/2017:15:23:56 +0000] "GET /content/control/main HTTP/1.1" 200 8946 "https: //demo-trunk.ofbiz.apache.org/ecomseo/additem" [01/Mar/2017:15:23:58 +0000] "GET /ecomseo/quickcheckout HTTP/1.1" 200 10396 "https: //demo-trunk.ofbiz.apache.org/ecomseo/additem" [01/Mar/2017:15:23:58 +0000] "GET /content/contentForum.css HTTP/1.1" 302 - "https: //demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout" [01/Mar/2017:15:23:58 +0000] "GET /content/control/main HTTP/1.1" 200 8946 "https: //demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout" [01/Mar/2017:15:24:05 +0000] "POST /ecomseo/login HTTP/1.1" 302 - "https: //demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout" [01/Mar/2017:15:24:05 +0000] "GET /ecomseo/quickcheckout HTTP/1.1" 200 28992 "https: //demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout" [01/Mar/2017:15:24:05 +0000] "GET /content/contentForum.css HTTP/1.1" 302 - "https: //demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout" [01/Mar/2017:15:24:05 +0000] "GET /content/control/main HTTP/1.1" 200 8946 "https: //demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout" [01/Mar/2017:15:24:12 +0000] "GET /ecomseo/logout HTTP/1.1" 302 - "https: //demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout" [01/Mar/2017:15:24:12 +0000] "GET /ecomseo/ HTTP/1.1" 404 236 "https: //demo-trunk.ofbiz.apache.org/ecomseo/quickcheckout" 2017-03-01 15:23:55,147 |ajp-nio-8009-exec-1 |ControlServlet |T| [[[main(Domain:https: //demo-trunk.ofbiz.apache.org)] Request Done- total:1.671,since last([main(Domain:http...):1.671]] 2017-03-01 15:23:55,147 |ajp-nio-8009-exec-1 |SeoContextFilter |W| [Filtered request]: /ecomseo/ 2017-03-01 15:23:55,592 |http-nio-8443-exec-8 |ControlEventListener |I| Creating session: hidden sessionId by default . 2017-03-01 15:23:55,592 |http-nio-8443-exec-8 |ControlServlet |T| [[[setSessionTimeZone(Domain:https: //demo-trunk-ofbiz.apache.org)] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]] [...] 2017-03-01 15:24:12,759 |ajp-nio-8009-exec-8 |ControlServlet |T| [[[logout(Domain:https: //demo-trunk.ofbiz.apache.org)] Request Done- total:0.021,since last([logout(Domain:ht...):0.021]] 2017-03-01 15:24:12,834 |ajp-nio-8009-exec-10 |SeoContextFilter |I| Can NOT forward this url: /ecomseo/ Have a look at console.log-trunk.txt.zip and access_log-trunk.txt for more. Anyway this should not block us to use a certificate for at least trunk and stable as a start. So I'll also commit stable and will work on OFBIZ-9240 locally to try to understand they underlying reason which seems to lay in SeoContextFilter class. I have tried to tweak SeoConfig.xml w/o results.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Fixed in R16.11 at revision: 1785014
          Backported in R15/14 at revision: 1785027 (note: ecommerce/ecomseo don't work there)

          Show
          jacques.le.roux Jacques Le Roux added a comment - Fixed in R16.11 at revision: 1785014 Backported in R15/14 at revision: 1785027 (note: ecommerce/ecomseo don't work there)
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Actually I just found the refresh needed issue is not only in logout but each time you pass before in login. For instance, not being logged, getting to profile implies that you need to login. Once logged in, you get a blanck page in stable before refreshing and seeing the profile page.

          It's even worse in old where the port 28080 is appended to the demo-old.ofbiz.apache.org domain. I did not change the home page after r1785098 for this reason, to be revisited... In the meantime it works well using the ofbiz-vm2.apache.org:port URLs

          Show
          jacques.le.roux Jacques Le Roux added a comment - Actually I just found the refresh needed issue is not only in logout but each time you pass before in login. For instance, not being logged, getting to profile implies that you need to login. Once logged in, you get a blanck page in stable before refreshing and seeing the profile page. It's even worse in old where the port 28080 is appended to the demo-old.ofbiz.apache.org domain. I did not change the home page after r1785098 for this reason, to be revisited... In the meantime it works well using the ofbiz-vm2.apache.org:port URLs
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I for now decided that I'll not handle the certificate for the old demo. Too much troubles! So I reverted all related changes at revision: 1785276

          Show
          jacques.le.roux Jacques Le Roux added a comment - I for now decided that I'll not handle the certificate for the old demo. Too much troubles! So I reverted all related changes at revision: 1785276
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          OK, this is basically done (I give up for old). The rest is in OFBIZ-9240

          Show
          jacques.le.roux Jacques Le Roux added a comment - OK, this is basically done (I give up for old). The rest is in OFBIZ-9240

            People

            • Assignee:
              jacques.le.roux Jacques Le Roux
              Reporter:
              jacques.le.roux Jacques Le Roux
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development