Nqorksta Posted August 8, 2013 Posted August 8, 2013 Hi everybody Since some days I have a problem with the admin page. I use an SSL-certificate and the browser indicates that parts of the page are insecure and blocks them. By blocking the formatting of the left menu is smashed and the graphs are not shown. Strange enough, that this error appears on almost every site in /admin as index.php, configuration.php or modules.php, except on some custom configuration pages from an add-on, where there is no error, formatting and encryption are as they should be. Neither is there an error with the encryption in the front-end catalogue. I have recently moved to a new IP address and updated the server from ubuntu 8.04 to ubuntu 10.04. And I got a new SSL-certificate. But I don't know where the problem could be found. Does someone have an idea how to solve this problem? Thank you in advance. Martin
MrPhil Posted August 8, 2013 Posted August 8, 2013 Why is your entire admin under SSL? That gains you nothing, and as you've found out, osC is likely to have some hard coded http: URLs on any given page (except those designed to be used under SSL). Just let osC put the pages it wants to under SSL. You don't say what version of osC you're using, but the "admin" directory should have been renamed to something unguessable and should be password-protected (which is not the same as SSL). If you're on ancient versions of osC, there are many other security holes that need to be patched.
Nqorksta Posted August 9, 2013 Author Posted August 9, 2013 Hi MrPhil, thank you for your answer. You don't say what version of osC you're using 2.3.3 the "admin" directory should have been renamed to something unguessable and should be password-protected I have done both. Why is your entire admin under SSL? That gains you nothing, and as you've found out, osC is likely to have some hard coded http: URLs on any given page (except those designed to be used under SSL). Just let osC put the pages it wants to under SSL. That's what I do with the front-end catalogue where pages like account.php or login.php are under SSL, and index.php is not. I didn't know that the admin works the same way. It seems that it is OSC that decides to keep the admin area in SSL.
♥14steve14 Posted August 10, 2013 Posted August 10, 2013 Let oscommerce decide what pages to use ssl on. Undo what changes you may have made, and just alter the cofigure files so that define('ENABLE_SSL', is set to true. Oscommerce will then set ssl on the pages that its supposed to be on such as the create account and checkout pages. REMEMBER BACKUP, BACKUP AND BACKUP
Nqorksta Posted August 10, 2013 Author Posted August 10, 2013 Hi 14steve14 That is what I have all the time - in [admin]/includes/configure.php define('ENABLE_SSL_CATALOG', 'true'); and in includes/configure.php define('ENABLE_SSL', 'true'); OSC decides on the catalogue front-end but I have never seen it doing so in the back-end admin.
Nqorksta Posted August 15, 2013 Author Posted August 15, 2013 There were never problems with the admin back-end until 2 weeks ago, when I updated my server to Ubuntu 10.04 and obtained a new SSL certificate. Now the browser still blocks the Javascripts on most of the admin pages, and that is why the whole formatting is smashed, especially the side menu and the graphical admin page modules. Does anyone have an idea?
Nqorksta Posted August 15, 2013 Author Posted August 15, 2013 Ok, I found the solution myself: I changed in catalog/[admin]/includes/template_top.php all links that look like <script type="text/javascript" src="<?php echo tep_catalog_href_link('ext/jquery/jquery-1.8.0.min.js'); ?>"></script> to <script type="text/javascript" src="../ext/jquery/jquery-1.8.0.min.js"></script> A little bit trickier around line 33 <script type="text/javascript" src="<?php echo tep_catalog_href_link('ext/jquery/ui/i18n/jquery.ui.datepicker-' . JQUERY_DATEPICKER_I18N_CODE . '.js'); ?>"></script> to <script type="text/javascript" src="../ext/jquery/ui/i18n/jquery.ui.datepicker-'<?php echo JQUERY_DATEPICKER_I18N_CODE ?>.js"></script> I guess the problem had to do with the update to a newer PHP version on my server.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.