https on one page only
Permalink 2 users found helpful
Is there a way to force force only a couple of pages to load in https. Right not I have defined the base url with https and it works fine, but slows page loading.
I really only need the secure page on the checkout.
I have tried to send the action of an external form to the urlhttp://somedomain.com, but it will always default to the base url.
any ideas?
I really only need the secure page on the checkout.
I have tried to send the action of an external form to the urlhttp://somedomain.com, but it will always default to the base url.
any ideas?
I have tried this, but because the base url is set to http, even if I type in the https, it will revert back to http.
Hope that made sense
Hope that made sense
This way?
and My custom template of page navigation block.
if($c->getAttribute('require_ssl')){ header("Location: ".ereg_replace("http://","https://",$base_url)); }
and My custom template of page navigation block.
if($_c->getCollectionAttributeValue('require_ssl') && !$c->getCollectionAttributeValue('require_ssl')){ $pageLink = ereg_replace("http://","https://",BASE_URL.$pageLink); }else if(!$_c->getCollectionAttributeValue('require_ssl') && $c->getCollectionAttributeValue('require_ssl')){ $pageLink = BASE_URL.$pageLink; }
Thanks guys,
these things worked perfectly
-JD
these things worked perfectly
-JD
Best way to do this is by adding the checkbox attribute as noted then adding the following code:
$pagessl = $c->getAttribute('require_ssl');
if ($pagessl != '1') {SSLoff();}else{ SSLon();}
//==== Redirect... Try PHP header redirect, then Java redirect, then try http redirect.:
function redirect($url){
if (!headers_sent()){ //If headers not sent yet... then do php redirect
header('Location: '.$url); exit;
}else{ //If headers are sent... do java redirect... if java disabled, do html redirect.
echo '<script type="text/javascript">';
echo 'window.location.href="'.$url.'";';
echo '</script>';
echo '<noscript>';
echo '<meta http-equiv="refresh" content="0;url='.$url.'" />';
echo '</noscript>'; exit;
}
}//==== End -- Redirect
//==== Turn on HTTPS - Detect if HTTPS, if not on, then turn on HTTPS:
function SSLon(){
if($_SERVER['HTTPS'] != 'on'){
$url = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
redirect($url);
}
}//==== End -- Turn On HTTPS
//==== Turn Off HTTPS -- Detect if HTTPS, if so, then turn off HTTPS:
function SSLoff(){
if($_SERVER['HTTPS'] == 'on'){
$url = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
redirect($url);
}
}//==== End -- Turn Off HTTPS
to the header_required.php file in the elements folder. Just place this code after the final if bracket,right before the closing php bracket.
Hope this helps.
$pagessl = $c->getAttribute('require_ssl');
if ($pagessl != '1') {SSLoff();}else{ SSLon();}
//==== Redirect... Try PHP header redirect, then Java redirect, then try http redirect.:
function redirect($url){
if (!headers_sent()){ //If headers not sent yet... then do php redirect
header('Location: '.$url); exit;
}else{ //If headers are sent... do java redirect... if java disabled, do html redirect.
echo '<script type="text/javascript">';
echo 'window.location.href="'.$url.'";';
echo '</script>';
echo '<noscript>';
echo '<meta http-equiv="refresh" content="0;url='.$url.'" />';
echo '</noscript>'; exit;
}
}//==== End -- Redirect
//==== Turn on HTTPS - Detect if HTTPS, if not on, then turn on HTTPS:
function SSLon(){
if($_SERVER['HTTPS'] != 'on'){
$url = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
redirect($url);
}
}//==== End -- Turn On HTTPS
//==== Turn Off HTTPS -- Detect if HTTPS, if so, then turn off HTTPS:
function SSLoff(){
if($_SERVER['HTTPS'] == 'on'){
$url = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
redirect($url);
}
}//==== End -- Turn Off HTTPS
to the header_required.php file in the elements folder. Just place this code after the final if bracket,right before the closing php bracket.
Hope this helps.
Normik what's better with your way compared to Tao's way?
A few things actually.
1) He uses ereg_replace which is depreciated and PHP highly discourages its use.
2) My method is in the core and is not theme specific. So if you change your theme,you don't need to add this code again.
3) Mine will try php headers first and if that fails it will try java redirect and if that fails it will try html redirect.
Number 3 is very important if you are dealing with other peoples personal information, passwords, emails addresses, etc.
If a programmer just does a php direct and a person (not knowing any better) logs in to what is suppose to be a secured site and its not because the php direct failed, what do you think the end result could be?
Its all about protecting yourself as much as possible when you're dealing with securing a site.
Hope this answers your question.
1) He uses ereg_replace which is depreciated and PHP highly discourages its use.
2) My method is in the core and is not theme specific. So if you change your theme,you don't need to add this code again.
3) Mine will try php headers first and if that fails it will try java redirect and if that fails it will try html redirect.
Number 3 is very important if you are dealing with other peoples personal information, passwords, emails addresses, etc.
If a programmer just does a php direct and a person (not knowing any better) logs in to what is suppose to be a secured site and its not because the php direct failed, what do you think the end result could be?
Its all about protecting yourself as much as possible when you're dealing with securing a site.
Hope this answers your question.
"1) He uses ereg_replace which is depreciated and PHP highly discourages its use."
Exactly. we must be use to preg_replace() or other way.
Nornik's way is better.
But I'm using javascript and html redirect feel uncomfortable about.
I think this feature should be implemented in the c5 core
Exactly. we must be use to preg_replace() or other way.
Nornik's way is better.
But I'm using javascript and html redirect feel uncomfortable about.
I think this feature should be implemented in the c5 core
I disagree with this approach -- I think jgarcia and Tao's approach is better, aside from the ereg_replace thing -- no reason to use a regex here when str_replace('http:', 'https:', BASE_URL) works just fine. Also I would add "exit;" after the "header('Location....')" call to ensure no other output is sent to the browser afterwards.
As long as you make sure the attribute check and subsequent header() call are the very first thing in your template (so put it ABOVE the opening <html> element, and make sure there are no spaces before your opening <?php tag), and add a call to "exit" right after it, there is no reason to think this would fail. This is not a "php" redirect, but rather a header redirect, which is part of the HTTP spec and supported by every browser ever. The "Java" redirect as you call it (it's actually javascript) is totally unnecessary.
Also, it is a best practice to NOT change any core system code, because it will get overwritten when you upgrade your system. I understand what you're saying about having this work even if the theme changes, but I think it's much more likely that you're going to upgrade your system at some point then change the theme and forget to put this in the new theme you switch to. And if your theme has a "header.php" element like most do, then you only need to put this in one place.
Just my two cents.
-Jordan
As long as you make sure the attribute check and subsequent header() call are the very first thing in your template (so put it ABOVE the opening <html> element, and make sure there are no spaces before your opening <?php tag), and add a call to "exit" right after it, there is no reason to think this would fail. This is not a "php" redirect, but rather a header redirect, which is part of the HTTP spec and supported by every browser ever. The "Java" redirect as you call it (it's actually javascript) is totally unnecessary.
Also, it is a best practice to NOT change any core system code, because it will get overwritten when you upgrade your system. I understand what you're saying about having this work even if the theme changes, but I think it's much more likely that you're going to upgrade your system at some point then change the theme and forget to put this in the new theme you switch to. And if your theme has a "header.php" element like most do, then you only need to put this in one place.
Just my two cents.
-Jordan
You're looking alittle bit too close into the short hand typing used in the scripting.
Yes there is Java and then there is Javascript. Both named by Sun and both are totally different from each other. I used Java in short terms of Javascript since it's clear in the code that the script type equaled javascript. Really didn't think anyone would get confused about it but if they did, I apologize.
Second, technically you are right and so was I in the term of PHP redirect. Header() is php but what it calls is HTTP. Header() can not run without php so technically php is requesting the redirect to the http headers. Yet again I really didn't think it was necessary to go into all that so I kept it simple.
Finally, while there may not be a need for javascript to play a part here as header redirect through php probably will not fail, it is a fail safe. Hiccups happen and who is to say PHP won't change their head() and how it acts. A new release of php could have bugs in it that affect this. Honestly so could new and updated browsers. When I do work for a multi billion dollar corporations, I would rather put a few extra lines of code as a fail safe and hope its never needed then not at all (especially when dealing with information that is suppose to be secured).
I do agree the core may not be the best place because of updates but based on the structure of C5, it seemed to be the best place for this under current distributions. Whether its C5 doing an update or a person updating their theme, you'll still have to look to see that whatever code you use is still there and in the right place. So what does it matter, really.
The code I posted is best for the content I secure because it has fail safes (which could fail too but are still there). So both will work just fine it all depends on which one you prefer.
Anyone have change for a quarter? J/K
Yes there is Java and then there is Javascript. Both named by Sun and both are totally different from each other. I used Java in short terms of Javascript since it's clear in the code that the script type equaled javascript. Really didn't think anyone would get confused about it but if they did, I apologize.
Second, technically you are right and so was I in the term of PHP redirect. Header() is php but what it calls is HTTP. Header() can not run without php so technically php is requesting the redirect to the http headers. Yet again I really didn't think it was necessary to go into all that so I kept it simple.
Finally, while there may not be a need for javascript to play a part here as header redirect through php probably will not fail, it is a fail safe. Hiccups happen and who is to say PHP won't change their head() and how it acts. A new release of php could have bugs in it that affect this. Honestly so could new and updated browsers. When I do work for a multi billion dollar corporations, I would rather put a few extra lines of code as a fail safe and hope its never needed then not at all (especially when dealing with information that is suppose to be secured).
I do agree the core may not be the best place because of updates but based on the structure of C5, it seemed to be the best place for this under current distributions. Whether its C5 doing an update or a person updating their theme, you'll still have to look to see that whatever code you use is still there and in the right place. So what does it matter, really.
The code I posted is best for the content I secure because it has fail safes (which could fail too but are still there). So both will work just fine it all depends on which one you prefer.
Anyone have change for a quarter? J/K
Hi,
In what file do I do this changes?
regs,
Alvaro
In what file do I do this changes?
regs,
Alvaro
Any new thoughts on this (this thread is a bit dated)? I have this issue and the biggest problem is that with all relative links, once the user has visited the https page, all links and subsequent page views will use the https protocol (which I don't want!)
So, two questions:
1. Is there any better solution out there than indicated here (at the end) as a best practice, and
2. How do I handle the problem of the https protocol being added to my relative links?
So, two questions:
1. Is there any better solution out there than indicated here (at the end) as a best practice, and
2. How do I handle the problem of the https protocol being added to my relative links?
Any new thoughts on this (this thread is a bit dated)? I have this issue and the biggest problem is that with all relative links, once the user has visited the https page, all links and subsequent page views will use the https protocol (which I don't want!)
So, two questions:
1. Is there any better solution out there than indicated here (at the end) as a best practice, and
2. How do I handle the problem of the https protocol being added to my relative links?
So, two questions:
1. Is there any better solution out there than indicated here (at the end) as a best practice, and
2. How do I handle the problem of the https protocol being added to my relative links?
Create a checkbox page attribute called "require_ssl" or something like that. Make sure it is checked on the page that you want to redirect to SSL on. Then, in your theme, add this code: