Thread

Hi All,
It’s been a while. A site I installed expression engine onto that had been working fine under version 1.6.3 until now (for more than two years) is now posing a login problem.

I have been able to reset my password but when I try to login with my user/pass I am taken to a blank page (with no red messages) that has empty fields.

We have recently had a ddos attack and are now filtering out traffic though a proxy server. Would this cause the login to stop working?

I have also tried to update to the newest version of ee after renewing my commercial license but although i have set the proper permissions (777) on my config.php and config.bak.php files I receive an error that says ‘Your config.php file is not writable.’

Can anyone shed some light on the situation?

I would be forever greatful.

Thanks,
Looking forward to ee 2.

L

lemonman,

If you are in the middle of an upgrade lets try and get you through that first. You have incorrect permissions set on your config file.

If you are using a Unix server you must set the following files to 666:

  system/config.php
  system/config_bak.php

You must set the following directories to 777:

  system/cache/ (and its contained folders)

Have you had any successful login since the proxy server was setup?

Thanks.
That was done. I am very familiar with the upgrade process as I have been using expression engine since 2005.
I also manage several dedicated servers…

Yes, got in to see the first screen of the login page then clicked edit, and it went directly back to the login page with a blank username and password with no error messages written in red, as is normally the case in a failed login attempt.

What’s the situation when the license expires on a commercial license?
I have a newly renew key in the config file but, could EE have locked me out remotely because my license was not valid?

I also set the domain cookie as Lisa mentioned in one of here earlier posts but the config file is just as it operates on my local wamp installtion. (by the way, did i mention that the site work locally without any problems?)

In additon I have tried accessing the site via ip address AND domain name…

Any help would be much appreciated.

lemonman,

OK a couple of things to try.

FTP into system/cache and delete all files there except for index.html

Delete your browser cookies and cache and restart it.

Could you add the following line to system/config.php

$conf['cookie_domain'] = "";

What advise from Lisa did you follow previously?

Tried that. That’s what Lisa mentioned in one of here posts.(cookie domain thing).

Still nothing.

Any chance we can bring one of the developers with a hardware/networking specialization background in on this?(no offense)
I really think that our ddos solution may be interfering but am not sure how.

I really think that our ddos solution may be interfering but am not sure how.

Can you go into more detail?

We route all our traffic through another server which determines whether or not the traffic is legit. If it is, it passes it back to our site, and the user is asked to enter a ‘captcha’ code. Once that is done that ip is whitelisted and the user is no longer asked for captcha to view the site.

I am able to see any other type of files that i need without problems, and as mentioned earlier, have been able to reset my password successfully. Just can’t interact with the cp.

Here’s an addition to my post that comes from our ddos attack solution provider.

“for the DOS protection you have pointed your domain over to a IP address which runs a proxy server. Then our proxy passes the request to your web server, which then responds to the proxy. Our proxy service then sends that response to the visitor.

  Could you please bring that up in the forum ports you made, then ask if there is any issues in the code which would conflict with that setup.

  MySQL should not be effected. Can you check out your database configuration and make sure it’s not directing to your domain. Our proxy only handles ports 80/443 (http/https). Everything else is blocked.”

Hi, lemonman - check out this the hidden configuration item: proxy_ips.  I think setting that up should help here.

Ok here’s what we got from the ddos solution provider.
They were hoping to get some feed back as to the following two hacks.

the issue is that EE needs to see the clients true ip address and
obviously a proxy would break that, not just with us but with any proxy.

so here is the hack #1

http://$site/index.php
$EE_host_ip —> $remote_addr

at this stage:
the $remote_addr = $ypf_proxy_ip & not the clients true src ip

$EE_host_ip—> $x-forwarded-for
the $x-forwarded-for = the clients true ip address that gets placed by
us inside the header

this would solve all your CMS issues, can you run this by the EE admins
and see what variable would need to be changed in the code to allow for
this to take place?

Hack #2
the EE script relies on apache (or other back end webserver) to feed it
the required visitors ip address via $remote_addr variable. One way to
bypass all of this is to force apache to look at X-Forwarded-For in the
request header and assign the value to $remote_addr, making all
connections look as if they are coming from the clients real ips and not
the proxy server.

Also just wanted to mention that hidden configuration item: ‘proxy_ips’ was added as need with a huge list of class c’s but still did not work….

Let’s try another config override.

In your config.php file, please look to see if you have the following line, if so alter it, if not add it:

$conf['admin_session_type'] = 's';

And try to log in again.

-greg

Nope. Still nothing.
Could someone read through our hacks and let me know what they think?