Any PHP guru's on here??

mwrpoole said:

I'm in the process of upgrading PHP from 5.3.5 to 5.4.17 to meet some Windows security issues. Also had to upgrade Apache as well from 2.2.22 to 2.4.4

Got it working on a test server and all my systems work fine after a few tweaks, but they don't work in IE. Firefox & Chrome absolutely fine but not IE. Its very strange, i can launch the systems in IE but can't log in to them, using the same credentials that work in Firefox & Chrome - its as if the the credentials are wrong but i know they're not. Been googling for hours but can't find anything helpful.

I'm hoping there's a setting somewhere in php.ini that sorts this but can't find anything. Any suggestions very much appreciated.

Before you ask, all customers are public sector bodies and IE is the only option for them, and usually IE7 or IE8.

Click to expand...

bashlsdir said:

That is a weird one indeed. Obviously nothing to do with the php code because like you say it worked before. Are you using a php package? is it forum, wordpress or bespoke code?
I guess your also using IE7 or IE8 to check it?

I presume MySQL is your database too?

View the source in IE and view the souce in Firefox of your login pages, when the pages are rendered in the browser, compare them
If you have uploaded a php file on to a windows server, I have seen it before with php where misc character have been inserted. It might be messing with the input boxes on the form.

Click to expand...

mwrpoole said:

It is bespoke code and yes I'm using MYSQL. I've tried IE7, 8, 9 & 10 just in case but no joy. I'll check the source out, the way its acting is identical to me entering incorrect login details, its almost like its not saving them in IE so it will never login.

Click to expand...

Brovion said:

PHP runs on the server does it not? So I don't think it's the PHP code as such, but problems rendering it in the browser. If it's IE try turning on the Show Script Errors and turning off the Show friendly URL messages or whatever it is. See if that gives you any pointers.

Click to expand...

binky said:

My instinct is that this is probably not PHP, where code interpretation changes between versions tend to break the scripts, but with your upgrade of apache.

Some major changes were made to Apache authentication/authorisation between 2.2 and 2.4.
Additionally, when upgrading apache versions, my biggest bugbears have been missing elements of the config which have changed. It takes ages to track down as the .conf files are understandably, not compatible between versions.

I found this, which may be a simple thing for you to try, and explains the IE vs FF/Chrome thing...
http://stackoverflow.com/questions/3532360/ie8-not-working-with-apache-basic-auth

Click to expand...

binky said:

do you have any overrides in .htaccess files which could be affecting the outcome? (Local .htaccess files override the apache .conf files)

Are you using the (folder based) security provided by Apache via htaccess, or do you have your own custom user/password process?
Are you authenticating using LDAP, or against a passwds file?


Off the wall question... (prompted by a problem I had with chrome...), is your site embedded in an iframe, or deep inside a frameset, or is it the top level document.

Try removing your redirect, and see if that cures the problem.

Click to expand...

bashlsdir said:

I reckon your solution above will solve his problem. Keep ticking off the list, he is nearly there. By the sounds of his first post he is running a WAMP server. Never installed in Windows before, putting .htaccess file on Windows seems a bit alien. Does it work in the same way as on a Linux server?

And what about the paths how does that work i.e on Linux /home/user/www/ on Windows would it be c:

Click to expand...

mwrpoole said:

No its not WAMP -PHP, Apache & MYSQL are all installed individually. We do have our own .htaccess file in our own htdocs folder, and the .conf file is configured to look at our htdocs directory via the DocumentRoot setting. 75% of our customers we host ourselves on Linux, but the other 25% want it installed onsite and always using Windows, and it always causes problems.

I've been told that the problem is that IE is not saving our cookies, so when the user tries to log in the authentication data is lost. Not sure if that is a PHP or APache issue, or how to fix it, but getting there slowly.

Click to expand...

bashlsdir said:

I presume when the user logs in, it checks the credentials and a session is created?
Can you find the folder where the session is being created after login?

If you can login with Firefox, check to see if the session is created. Do the same with IE. If the session is not being created try changing the destination where sessions are stored using an .htaccess file, see if that works.
http://www.techheadz.co.uk/205.htm

I also found this info that seems to be on the right path
http://stackoverflow.com/questions/...net-explorer-cookies-are-working-great-though

Click to expand...

mwrpoole said:

The issue is now sorted, and the cause was as follows:

In Apache I had 2 hosts set up with server names of pmqa_test & sf_test;
In IE, Chrome & Firefox simply entering a URL or pmqa_test or sf_test launched the relevant systems;
In IE you couldn't log in;
It turns out that IE doesn't like URL's with an '_' in them. It can't save data, such as log in credentials in the cookies;
Changed the server names to pmqatest & sftest and all works fine now in all browsers.

A simple explanation that that took ages to identify.

Click to expand...

mwrpoole said:

The issue is now sorted, and the cause was as follows:

In Apache I had 2 hosts set up with server names of pmqa_test & sf_test;
In IE, Chrome & Firefox simply entering a URL or pmqa_test or sf_test launched the relevant systems;
In IE you couldn't log in;
It turns out that IE doesn't like URL's with an '_' in them. It can't save data, such as log in credentials in the cookies;
Changed the server names to pmqatest & sftest and all works fine now in all browsers.

A simple explanation that that took ages to identify.

Click to expand...

The Internet standards (Request for Comments) for protocols mandate that component hostname labels may contain only the ASCII letters 'a' through 'z' (in a case-insensitive manner), the digits '0' through '9', and the hyphen ('-'). The original specification of hostnames in RFC 952, mandated that labels could not start with a digit or with a hyphen, and must not end with a hyphen. However, a subsequent specification (RFC 1123) permitted hostname labels to start with digits. No other symbols, punctuation characters, or white space are permitted.

Click to expand...