Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

"Cookie 'alc_enc' can't be set" error and shared hosting


Reply


4 Posts   859 Views

Avatar
Tama

Community Member, 130 Posts

19 November 2012 at 4:42pm

Howdy

We've setup a client's 2.4.6 SS website on a shared host, and everything is fine except logging into the CMS returns this error:

[User Warning] Cookie 'alc_enc' can't be set. The site started outputting was content at line 71 in /home/heartofb/public_html/buzzit-core/_config.php
POST /Security/LoginForm

Line 33 in /home/heartofb/public_html/sapphire/core/Cookie.php

I've spent a couple of hours searching the forum/ internet for a solution, with no luck.

The website is on a shared server using "Cpanel X" - which is a new environment for us to work in. I was wondering if something about the shared environment is causing this problem.

We just FTPed the site across from another server, instead of going through the install process so there may be issues with the php configuration that haven't been picked up. What's the best way of running the pre-install check without damaging the site?

If anyone has any experience with this error or Silverstripe on shared server it'd be great to here possible solutions for this issue.

Cheers
Tama

Avatar
Tama

Community Member, 130 Posts

20 November 2012 at 2:00pm

I've made some progress. The issue we're having seems to be caused by Silverstripe delivering a HTML/meta/Javascript redirect, instead of the standard 302 redirect.

I placed a sniffer against it and on the dev server going to /admin returns the standard 302 redirect. While going to /admin on the hosted site returns a 200 with the following content:

<p>Redirecting to <a href="/Security/login?BackURL=%2Fadmin" title="Please click this link if your browser does not redirect you">/Security/login?BackURL=%2Fadmin... (output started on /home/heartofb/public_html/buzzit-core/_config.php, line 71)</a></p>
         <meta http-equiv="refresh" content="1; url=/Security/login?BackURL=%2Fadmin" />
         <script type="text/javascript">setTimeout('window.location.href = "/Security/login?BackURL=%2Fadmin"', 50);</script>

This all seems to come from the output() function in /sapphire/core/control/HTTPResponse.php - Line: 215

      if(in_array($this->statusCode, self::$redirect_codes) && headers_sent($file, $line)) {
         $url = $this->headers['Location'];
         echo
         "<p>Redirecting to <a href=\"$url\" title=\"Please click this link if your browser does not redirect you\">$url... (output started on $file, line $line)</a></p>
         <meta http-equiv=\"refresh\" content=\"1; url=$url\" />
         <script type=\"text/javascript\">setTimeout('window.location.href = \"$url\"', 50);</script>";
      } else {
         if(!headers_sent()) {
            header($_SERVER['SERVER_PROTOCOL'] . " $this->statusCode " . $this->getStatusDescription());
            foreach($this->headers as $header => $value) {
               header("$header: $value");
            }
         }

Which suggests some sort of fallback in action? Does Silverstripe try to use this fallback when it can't redirect by normal methods?

Does anyone have any experience with this issue?

Avatar
Tama

Community Member, 130 Posts

20 November 2012 at 2:37pm

I've worked out the problem. It was an older version of SS which had a HTTPResponse class - which clashed with a HTTPResponse class defined by the hosts PHP.

So I'm upgrading the site to 2.4.8 - which uses SS_HTTPResponse instead.

More info here: http://www.silverstripe.org/installing-silverstripe/show/5608

Avatar
_Vince

Community Member, 161 Posts

8 July 2013 at 9:57am

Something else that seems to cause that problem, at least for me, is having a carriage return after the final closing "?>" in a PHP file. There's a post somewhere where (IIRC), Willr (?) suggests removing them and I find that it solves the problem. YMMV.