Thread

Hi,

I have an ExpressionEngine v2.1.3 site running on a subfolder installation.

I tried all possible combinations of admin session type mixed with cookie domains. But still not able to login to Control Panel.

My config.php settings are

$config['admin_session_type'] = "c";
$config['cookie_domain'] = "www.site.com";
$config['comment_word_censoring'] = "y";
$config['comment_moderation_override'] = "n";
$config['comment_edit_time_limit'] = "";
$config['enable_online_user_tracking'] = "n";
$config['enable_hit_tracking'] = "n";
$config['enable_entry_view_tracking'] = "n";
$config['dynamic_tracking_disabling'] = "";
$config['require_ip_for_login'] = "n";

Any help is appreciated

Vinay

Hi, artminister. For one thing, your cookie domain setting is off. It should be like

.yoursitename.com - with the leading . before the domain name.

When you attempt to login, what happens? Have you tried clearing your browser cache, or with a different browser altogether?

Hi Sue,

Yes i have tried with a leading .

Tried with all browsers with caches cleared. No of my other admins can login as well. The user just gets re-directed to login page. This is a live site too.

Hi Vinay,

Try setting

$config['cookie_domain'] = "";

then clear your browsers’ cookies and cache and try logging in again. Any luck?

Hi Brandon,

I have tried that. No luck. I have had problems like this with EE before on different sites and when i changed the session_type to cookies, it would be fine.

But this time, nothing works.

-Vinay

Vinay, I am just noticing that you are talking about a subdomain installation. I’m not sure how, but maybe other cookie-related items got set in the course of working this up.

You could try adding the following to config with your other settings, just to be sure you are zeroing everything out:

$config['cookie_path'] = "";
$config['cookie_prefix'] = "";

cookie_path is the one that tempted me to remark here.

I use cookie_prefix myself, one per subsite, to keep logins to different subdomains from interfering with each other. But for the moment, and in trying to log in to one site, with appropriate cache and cookie clearing before tests, probably you just want to make it blank for now.

Regards and good fortune,
Clive

edit just above: be sure you do any copy-pasting from the code block version of the configs in that message, as it had EE typopgraphy curly quotes in it before I fixed it.

Hi Clive,

Its not a subdomain installation, but a folder based site. Eg: http://www.site.com/expressionengine/

I have tried your suggestion of resetting the cookie path, but no luck.

- Vinay

Hmm. Well, that’s sounding a bit unusual, Vinay.

A first question is whether admin on this site has ever worked from the present installation. Or is it a case where it worked, on that site and not a test site, but suddenly now you can’t log in to the CP?

Also, I’m not sure we’re understanding exactly what you may mean by saying this is a ‘subdirectory site’. I am taking from your last comment that it’s a way you are using to mix EE into a presently otherwise operating site, so that you aren’t re-implementing the rest of the original in EE. In that case, site.com/expressionengine/ would give you the default page of the EE installation.

I had a look around on Google rather than the forum search, and this reminded of one or two things which might be involved.

- have you properly pathed the site themes for the CP? If I remember things I’ve seen, it won’t open without that access; may or may not give a PHP error which could be hard to see on the login screen. You would need added config like this:

$config['theme_folder_path'] = '/full/server/path/to/expressionengine/themes/';
$config['theme_folder_url'] = 'http://www.site.com/expressionengine/themes/';

It’s the first line that’s most important, needing to the full internal server path from server root (/). You can discover that if not sure by putting a temporary pathinfo.php file in the themes folder with the following contents, and then accessing that from a web browser:

<? print $PATH_TRANSLATED; ?>

Hoping this will get you on a path, Vinay, but do please let us know if it’s a fresh install that never allowed CP, or if the exact site configuration let CP work before but somehow has quit.

Clearly if you are using an .htaccess file, there are other things that could go wrong, and it is probably a good idea to rename it until you can get CP access working.

Regards,
Clive

Vinay, I got your PM—a very nice site, and you can’t ask for a more prominent client.

The subdirectory site is I can now see designed as above - you are operating EE as a part of a larger non-EE site, from the subdirectory.

For us to help you with suggestions, I think you have to answer clearly, so we understand more of the situation. That’s because there are many possibilities.

- Because the EE site is highly developed, the CP has to have let you log in before. But was this only on a test or development server?

- In other words, have you ever seen the CP work on the deployment server you are showing me, and did it then stop letting you log in, later? Or has it _never_ let you log in to the CP on this public deployment server?

- If you could log in only on a development server, but never on this deployment server, then I think the path and cookie issues we are showing you are likely to be where something is incorrect—or there is a general site issue as I will explain below.

- However, if you could at first successfully log in to the CP on this customer deployment server, and then suddenly could not log in, something in the environment has to be found, that has changed. This could be in your EE settings, but also could be in the server.

- What is causing the problem, either way, might not be in your direct control. For example, what if something in the customer deployment server prevented EE from setting cookies, perhaps as part of a security system, or a change in it?

Then cookie-based login to the CP would not be possible - in fact you would continue to get the login screen because the authentication cookie was never received by the browser to be sent back.

- in fact, when I use the URL you gave me for the EE section of the site, I can see no EE cookies being set, only ones from the main customer site, and from s7.addthis.com, which I think is a social media add-on site.

I believe I should see at least 3 cookies from EE, to record last activity, last visit, etc., from the EE front end, but I don’t. This leads me to believe that the customer server arrangement may be preventing EE’s cookie functions. Cookies as you probably know are a matter of HTTP headers, and a firewall might be preventing some. Or possibly the content I see doesn’t come from EE at all, even in that special ‘directory’ area, because of a setup mistake; though in that case you probably wouldn’t see a CP login either.

Vinay, you can look at these things, and it’s very late here, so we can hear from you afterwards.

One thing you might try, to bypass cookie issues, is to tell the CP to authenticate only by session_id, and not use cookies at all. For that, as I think you may know, you would set as follows, with the session type as “s” for session_id instead of “c” for cookie:

$config['admin_session_type'] = "s";
$config['cookie_domain'] = ""; /* or later ".site.com.sg" as you showed me, but no www */
$config['cookie_path'] = "";
$config['cookie_prefix'] = "";

Again, good fortune on seeing the issue here. If you have a development server where things work, you can identify the cookies that should be present.

Regards,
Clive

Hi Clive,

Thanks so much for the help. Let me get into detail on how the site is structured.

- The EE site is hosted on http://www.siteb.com, But the site is also accessible via the URL http://www.sitea.com/siteB. SiteA is not a EE site. The client do not want the EE site to be accessible via http://www.siteb.com but instead http://www.sitea.com/siteB
- SiteA and SiteB are not on the same servers. I know its kind of weird. But because of php version issues, they did this.
- So the clients is pointing http://www.sitea.com/siteB to my EE site which resides on a different server. They are using a proxy here.

So my CP url is http://www.sitea.com/siteB/system . I was able to login using this URL when i launched the site. But not now.

Answering Clives’ questions

1. This is a live site. And I could login to CP before. All of a sudden after a few days and no one making any change to EE files, it just stopped.
2. CP worked fine on my development server. And it still is.
3. I am not sure what the Client did to the server to prevent EE cookies from setting. I can check with the client.

I have tried using sessions, but no luck either.

Do you think the weird site setup is causing the cookie and session issue?

Also clive i have placed info.php in the root of my server. You can access it using the URL i PM’ed you.

Appreciate your help

Vinay

Hi Vinay, and thanks for very good answers—I think we are much closer to understanding this now.

- I understand and appreciate exactly what you’ve done now, and why, with the client’s need to integrate separate servers. It really is an unusual arrangement, but should be a sound one, thus should work well. And a good reason to do it.

- now, one important question to please answer also. You said you were still fine using the CP with your development server. Does this mean that you can still use the CP successfully, if you log in directly with http://www.siteb.com/system?

I think you see there, that we want to be sure the site CP is ok if you access it directly, so please confirm that part. You might have to use an IP (http://123.456.123.456/system) if there’s not a domain attached.

- I am going to assume until you tell me that this direct login works, and that would leave us with the proxy as the difficulty, or still, the main site firewall or other security.

I am going to have to think about this, and it’s far better if we let the EllisLab people think too. Since it may be too late for you to do it today, and since I am sure you will trust there, I am going to PM your site information to Sue and Brandon. They will also share with internal developers as needed so we can get best expertise on this situation.

- Given your answer above is yes, that direct access to the http://www.siteb.com/system CP is still working, then yes, it will be very appropriate ask the client about their proxy or security and the missing cookies. I think it will be best if you are well informed before doing so, but you have to make the judgement when it would be best to involve them vs. their concern.

At the right point, it will be very good for you to have an open teaming with the client’s website people to work out the answer, a friendly working together, and I just held back from suggesting it last night so we could give you best preparation. Then everyone can enjoy getting to the mystery and solution.

Let’s nail down that your http://www.siteb.com/system direct CP access is ok, and if you have to reset any of the config information to make it like your original development situation so that it is, and so you can show the client that it is. 

This is the first needful step, and it may also open an alternate working path for them until a fix can be understood, so that the client maintains their own access until all can work again more directly.

Let us know, Vinay, and thank you.

Regards,
Clive

Vinay, a little more information, and since it’s going to be the weekend in Singapore, possibly observing a holiday, by the time you see this, I am sure Ellis support will be watching as you come back about it.

- I did some looking, and as I expected, there are many ways for a proxy to not be set properly to pass cookies from your integrating site. As well, depending on where your server is located in an internet sense, there are also various possibilities for firewall problems.

- The reason for a change after it had first worked could be many things. Someone may have updated the customer server site settings, without realizing about your subsite’s presence or needs. Possibly they later re-arranged proxying to bring your site within a load-balancing server farm, and lost the necessary settings then.

- There are basic necessary configurations to have a reverse proxy properly pass cookies. For example, on apache ProxyPassReverseCookieDomain and ProxyPassReverseCookiePath are important. Other things might be wrong also, however, since your EE subsite’s cookies appear to be completely missing.

- to move forward, I would first be sure you can access the EE CP properly on the subsite production server when you connect to it directly, not through the customer site. You may be already saying you can, but you are saying it for a ‘development’ server. Again, if changed, you may need to return to some of your original EE config settings to enable this. And you may need to use IP access if there is not a domain associated with that subsite production server.

- Once you can demonstrate that direct connection is working properly, then I think you are ready to work with the customer. You might offer the direct connection as a temporary solution to any customer persons who are concerned about lack of present CP access to do update work.

- but then, I think you need to have a direct connection to the customer website administrators arranged. As we are seeing it, and given you have direct production subsite server CP access working, the problem has to be solved at their end. That no cookies at all are passed when proxied from your subsite should be a very useful piece of information for them. It’s a very large organisation, so they probably have strong procedures, and that’s likely what’s interfered here, before they know your subsite’s needs.

- I wanted to clear up one possible point, so that confusion doesn’t happen. The EE CP does have the session_id-only login, as you tried. But for the CP to work even with that type of login, the rest of the cookies have to be present - I count eight total cookies when logged into my 2.1.4beta CP here. In any case, cookies login has useful features, so you should be able to use it.

Ok, Vinay, and I know we will all be interested as this problem is solved. Then it will also become a very useful thread to find, for someone else in the future.

Regards, and I hope this lets you better enjoy the week-end,
Clive

Hi Clive,

Yes. Direct login works when i use the following settings

$config['admin_session_type'] = "c";
$config['cookie_domain'] = "siteB.com";

I have been using this setting to login to the site. But when i use direct login, File uploads don’t work because of security issues with wygwam (ckeditor). I am also worried if this arrangement (different control panel url from the site url) will affect other admin functionalities.

I really appreciate you providing me so much information. It really helps me a lot when i talk to the client. And this client is kind of slow and not that flexible when it comes to server configuration. Although I convinced them to switch to EE and ran the EE wizard prior to installation. I might also be working a few other campaigns for them, with similar setup.

As you mentioned, since i was able to login before with http://www.sitea.com/siteB/system, the issue might be some change in server configuration by the client. I am going to talk to them on Monday.

I will update this thread on Monday with info from the server guys.

Thanks a lot Clive

Cheers
Vinay

Sounds great, Vinay, and that you know just what you are doing. I kind of thought it might be that way with the client, so best prepared.

It should be a matter of professional capability with them, to get the proxy working. Of course that’s a two-edged sword, especially in Asia, so you’ll know how to work with that. And once this one is accomplished, everyone knows how to do it easily for those future campaigns.

On the Wygwam issue, I was going to send you straight to Brandon Kelly at pixel&tonic, as he would be pretty interested that all was smooth with that for a client like yours. However, I noticed a recent support thread with what sounds like it might have been a similar problem on his support site, here.

There’s a good set of troubleshooting ideas in this report, and the resolution was that there had been a file corruption in the Wygwam installation. Probably as always good ftp advice, removing all the Wygwam-related folders from third_party, and after that re-uploading it would clear such things, and may help you as it did in this case.

Thanks for coming back and letting us know, Vinay, and we’ll be interested as you complete the case.

You’re most welcome, on the help.

A nice weekend to you.

Clive