Thread

we can log into any member account from the USA.

our users cannot log into the control panel from singapore.(may be other places also) from their home computers and from their work computers.

we have tried:

- deleting all users browser history/cookies//cache on every browser (latest versions of firefox, chrome, safari)
- checked to see no errors in browser console for file requests, javascript errors etc.
- created new users accounts
- change passwords
- changing their account type to super admin
- changing dns of the users computer to google’s 8.8.8.8
- logging in through admin.php and /system
- currently we have tried these lax settings for session options http://d.pr/NryM
  - we have also tried multiple variations of those options with no success.

every time they try and log in the CP login screen just returns to the same page with no errors or warnings.

thanks.

Are you using the blacklist module?

Hm… another thing that comes to mind is this module: IP to Nation. You might need to update the database with a fresh list.

Last thought is Maxthon, but only because its my understanding that it’s widely used on that part of the globe.

Hope something there helps.

Hi Luke,

can you try adding this to your config.php please

$config['admin_session_type'] = "c";
$config['user_session_type'] = "c";
$config['require_ip_for_login'] = "n";
$config['require_ip_for_posting'] = "n"; 
$config['secure_forms'] = "n";

Hi there - I’m travelling in Singapore and I’m also having this issue.  I’d strongly suggest that you guys get access to a Singapore based VPN or local developer and test this one.  We haven’t had any user complaints, since most of our sites aren’t SE Asia focused, but it’s a definite issue and while it’s not mission critical to me personally, should presumably be classed as a pretty urgent fix.

I was here a couple of weeks ago and had issues with Devot-ee’s checkout system, but assumed it was site specific, and it resolved itself as soon as I was back home again.  This trip, I’m having sporadic issues logging into the CP and frontends from 2 different addresses (with different ISPs).

I’ve resorted to turning on my VPN to access the sites from a London-based connection, which solves the problem entirely, but that’s obviously completely impractical for users.  Having tested this out, no amount of tweaking the session type variables fixes it.  I’m seeing the issue on the 5 sites I tested, several of which were not built out from our master install, so it’s not just down to a specific issue in our setup that’s following through to all users.

I’m not going to be here long enough to debug fully, unfortunately, but it obviously needs attention.  Would be highly appreciated if this could be looked in to.  Thanks!

In addition to Jon, we have another customer from Singapore that is also having connection problems and cannot purchase from devot:ee. I’m not sure how I can help figure this one out.

Hi all,

We talked about this around the team here, and the only thing we’ve been able to come up with since it’s originating from a specific country is that Singapore itself may actually be blocking EE-powered sites. (It’s usually easy to tell when a site is powered by EE by looking at its cookies.)

Sean Smith, one of our intrepid Customer Advocates, used to live in Korea. His comments as we discussed this internally:

...When living in Korea periodically the government would blacklist urls and/or ips that contained content that was considered inappropriate for the nation to view.

Most South Koreans didn’t notice or complain about it, but when it happened there was often the side effect of innocent sites being taken down. For example one wordpress.com blog annoyed the gov’t and for several weeks all wordpress.com blogs were taken down. I also had my site inaccessable for 2 weeks because of a site not on my ip, but hosted by the same company as my site (site5) was blacklisted.

...This may be what’s happening in Singapore since it is relatively well known that the do engage in censorship from time to time.

Does anyone have any data on this from folks in Singapore or surrounding countries that might help us troubleshoot this?

Thanks Kevin.  I’m also assuming it’s something related to the network rather than individual sites. 

I don’t have much data, but I think it’s very relevant that there are no issues whatsoever with accessing the sites - the issue is to do with the authentication when you try to log in or submit certain forms, so I presume it’s cookie or session related as well.  We use Mountee to access a lot of our sites, and see the same problem there.

It’s also sporadic, and while I don’t think I’ve ever been able to click the Checkout button within Devot-ee’s cart, I can occasionally log in to the front and backend of some of our sites.

So admittedly not a huge amount of specific technical info, but hopefully that’s of some help when debugging this.  Hopefully there’s some kind of solution, as it’s not great from a business POV!

I agree, it’s definitely not a good experience. I want to get more feedback from the others to help us figure out whether or not it’s even something we can help remedy with EE.

Does anyone else have any information that’ll help us all get a clearer picture here?

we had sporadic success fixing this by using a url to the control panel that has a deeper link into the control panel (not the dashboard) with a return code like below but that has also now become totally unreliable and cant get it to work again:

i.e
/system/index.php?S=0&D=cp&C=login&return=Qz1jb250ZW50X2VkaXQ=

dont know if this helps anyone.

This is not a good thing when we are trying to launch a singapore companies’ website from the USA and the company cannot log in as you can imagine.

I am willing to have a remote skype call to troubleshoot this issue.

thanks.

I will add that this is a control panel issue (auth) not a site access issue. public templates are fine.

I have also tried all config settings around auth mentioned above by ellislabs support with no success.

this is also confirmed across latest chrome, latest firefox 9 & 10, and safari.

EDIT: oops, error post.

Hi Luke,

I’ll ping the Devs again to take a look at this thread and the extra information you’ve posted.

Sean

Hi Luke,

I was pointed to this post by the Devs as a possible solution. could you try this out and then report back here. If you have any additional information about this that would help us find the solution that would be great.

We had the same issue and in our case it was a matter of dynamic ip addresses in the clients network.  Every 10 minutes they switched.
After some digging around we ended up in the function fetch_session_data.  Regardless of your settings to require an ip address or not, it will try to match it with the one stored in the database.  Of course, when the ip switches, you get thrown out of the CP.

On line 700 of system/expressionengine/libraries/Session.php you will find the check for ip in the fetch session data function.  In the end we ended up commenting that one and that solved our issue.  It’s probably an edge case, but it’s worth a try.

public function fetch_session_data()
    {
        // Look for session.  Match the user's IP address and browser for added security.
        $this->EE->db->select('member_id, admin_sess, last_activity')
                     ->where('session_id', (string) $this->sdata['session_id'])
                     ->where('ip_address', $this->sdata['ip_address'])
                     ->where('user_agent', $this->sdata['user_agent']);

Sean

Hello Luke,

Have you had a chance to try what Sean suggested?

Is there anything else we can help you with or any more questions we can answer?

Looking forward to your response!

Cheers,

For some reason I am not getting updates to this thread. I have made Seans fix to the PHP, and will be testing tomorrow and will let you know.