Recently we upgraded a server from PHP 5.3 to 5.6. We tested all code internally before doing so, and all was well.
After the upgrade, everything works fine except for an extremely small portion of the clientele. We have an integration with a LOS called Calyx Pointe. A small portion of Pointe users are losing their sessions after loading a few pages. We cannot determine why.
They login and we see their session data. They choose an option and it redirects them to page #2, which still knows who they are. They choose an option on that page, which calls an AJAX GET call, and suddenly they're forgotten. I have verified that the AJAX called page includes the sessions code, so it should be fine. It's also called via the same domain, so there's no issue w/ multiple domains losing the session. Also, no _ in the domain name.
When we tested w/ the same version of Pointe, it works perfect for us. And we have done this on several different versions, using different underlying versions of Internet Explorer. (Also, a small portion of these users CAN place orders fine.)
So, 2 questions:
Does anyone know of any issue w/ the change in PHP versions that would cause this? We're not using mysql_* functions. The sessions are stored in a DB using a modified version of Zebra_Session. This started immediately after the upgrade (the next day), so I don't feel it's a coincidence. But, b/c we cannot reproduce the issue, it has made it extremely difficult to diagnose, as we cannot test from the client's machines.
Alternatively, would passing PHPSESSID in the URL to each page called w/in allow each page to "remember" the session?
Any ideas would be helpful and appreciated.
Related
I am a bit puzzled on using PHP's session. Are there any specific requirements or conditions to use sessions? From all other forums, I can only see that session_start() should be the first line of the php code and nothing else beyond that.
In my test server (with PHP 7.3) it took me a while to get it to work, the only thing I found out is that when I load my site using http, the session doesn't save across load. And when I load it using https, it works fine.
While at this topic, I am also confuse why this tutorial site: https://www.w3schools.com/php/php_sessions.asp doesn't work despite it loaded using https.
I recently started web development. The course I took was to install WAMP and start developing right away. I used an atom text editor, this -combined with wamp- proved to be a very fast way to write client-side code(HTML, CSS, Javascript).
But when I started to write serverside PHP things got a little messy. I should probably explain my site's structure here.
I keep separate PHP, CSS, javascript files for every page on the client side, for the server side a have 2 different types of PHP files:
Files that only perform a specific operation on the database(For example returning "5 more answers"). These are always called by AJAX requests.
Files that load the page for the first time. These are only used when the user opens the page for the first time, they do necessary database queries and return the page. Later requests always go to the 1st type of PHP files.
Now regarding my problem. I debugged until now by printing variables to the screen with var_dump() or echoing. But this started to become too slow as the data I work with grew. I wonder if there is a way of debugging which will let me but a breakpoint in one of my PHP files. Then, when I open it on the browser, on the localhost I created using WAMP, will let me go through the PHP file step by step.
I have been dealing with this issue for 3 days, I tried to make it work with Eclipse IDE but couldn't find a way. Also, there seems to be no tutorials or Q&A on the internet regarding the issue.
Breakpoint debugging opens a whole new world, and is the natural step after var_dump() debugging. Not only does it speed up development, but it provides much more information about your code, as you can step through each line and see what values have been set at each step, and how they evolve as your program executes its code. This means you can track the entirety of the values at different stages with one run - imagine tracking all variables at each point using var_dump()!
Although choosing an IDE is a personal decision based on personal taste, i strongly recommend you try out PhpStorm. If you can get a student licence go for it.
PhpStorm has extensive documentation & tutorials on all features in the IDE, debugging is no exception:
https://www.jetbrains.com/help/phpstorm/configuring-xdebug.html
https://www.youtube.com/watch?v=GokeXqI93x8
I don't know of a specific solution to your issue. I'm not exactly sure what you're doing but as a quick tip, I find add the following snippet to the top of the file useful as it will highly error more easily rather than browser just say nope.
error_reporting(E_ALL);
ini_set('display_errors', 'On');
Hope this help you a bit.
I tried out what's recommended in comments and answers. I first tried Netbeans. To be fair it disappointed me. Download kept getting stuck at 100%, even for different versions. When I stopped downloading and went ahead to create a php project, there was missing parts I guess. I couldn't even manage to create a php project. But that might just be me not being able to do it.
Then I followed #leuquim's answer and #Alex Howansky's comment and downloaded PHPStorm. And I got it to work in no more than 20 minutes. I downloaded it with a student's licence. For people who want to use PHPStorm with WAMP here's a Youtube tutorial:
https://www.youtube.com/watch?v=CxX4vnZFbZU
One thing to note in the video is that, maker of the video chooses PHP Web Application in the Run Configurations. That has been changed to PHP Web Page.
I made a full migration of the Drupal site (both code and DB).
At first sight site works fine. All the pages and page content are fully available.
But all the POST forms don't work. I tried to put test messages to form hooks. Form generation works fine, but both validation and send hooks were not even called.
Moreover, all standard forms (for example Sign Up Form) don't work too.
Just after submitting form fields become empty without any errors or warnings.
Looks like all the differences between environments are:
PHP version. (from PHP 5.4 to PHP 5.5)
Different path on server
Another domain name (dev/staging)
But, I'm not sure. I might missed something else.
Does anybody have any ideas what could cause this problem?
Well, the reason of the problem was very simple and so confusing at the same time.
It's not a Drupal-related issue, it's quite strange behavior of Apache Web Server.
The mod_rewrite was disabled in Apache configuration (shame on me). But, despite this fact, Apache was managing all redirects, thus pages were returning correct content but with 404 response code! It caused empty POSTs and, as result, broken forms.
I still can't realize why Apache behaves this way...
Anyhow,the problem was solved.
I have an old joomla installation which was hacked. All I know for now only index.php was changed and they messed with my user accounts. I downloaded index.php from the current version but at one point it calls $app->dispatch(); which requires a component name parameter in my version. Does anyone know what parameter this should be? I tried: null, 'home', 'application',...
Also I'm planning on updating to the newest version later, however I can't seem to find my current version number. I found somewhere that it is displayed in the admin pages but I can't access them yet. Can I find it in the code files somewhere?
EDIT: The index.php from version 1.5.22 worked. Apparently the correct version was 1.5.3. Does anyone know what else I should check that might have been hacked/messed with?
Why not get a copy of the version you used?
http://forum.joomla.org/viewtopic.php?p=2221953
You can go to the joomla project on
joomlacode.org, then select the search
tab. From there you type in "1.0.10"
and select Releases to search in. You
should get some results. Click on the
one you are searching for, the files
can be found on the files tab, this
time the tab is on a blue bar (more to
the bottom of the screen).
Although I'd recommend upgrading completely, to stop being re-hacked again.
====== Answer to second question
How big is the site? Usually if it's just a link spamming attack a quick once over will suffice.
The next issue is that you need to patch the hole that caused the problem, in this case upgrading to the latest Joomla (1.6 - I believe) is the first port of call.
Have you modifed the Joomla system in such a way that the hack could have been opened up by you?
My advice, reset the admin passwords and upgrade Joomla.
Very difficult to say anything else without seeing what the "hack" was.
I had to clean out a hacked Joomla install recently. My tip is to grep all the files base64_decode: some hacks consist of decoding a huge string that emits php.
find ./ | xargs grep base64_decode
The hack looked like this: error_reporting(0);eval(base64_decode('JGxMOXdGMWFZNHpY.....
This particular piece of code detected googlebot and other crawlers, and then emitted a list of spam links heavy on viagra. If a normal user agent string was used it showed a normal site. I had to use a firefox extension that changes the user agent to debug this.
The next step would be getting rid of the exploit and then either patching Joomla and waiting for the next exploit or switching to something more secure, like static html or a well-maintained CMS.
Fortunately Joomla has really nice documentation on how to recover from a hack. http://docs.joomla.org/Security_Checklist_7. As Pino mentioned, it is critical that you are always on the latest version to minimize your exposure to security exploits.
I think I may have found a bug in PHP's crypt() function under Windows.
However: I recognize that it's probably my fault. PHP is used by millions and worked on by thousands; my code is used by tens and worked on by me. (This argument is best explained on Coding Horror.)
So I'm asking for help: show me my fault. I've been trying to find it for a few days now, with no luck.
The setup
I'm using a Windows server installation with Apache 2.2.14 (Win32) and PHP 5.3.2. My development box runs Windows XP Professional; the 'production' server (this is an intranet setup) runs Windows Storage Server 2003. The problem happens on both.
I don't see anything in php.ini related to crypt(), but will happily answer questions about my config.
The problem
Several scripts in my PHP app occasionally hang: the page sits there on 'waiting for localhost' and never finishes. Each of these scripts uses crypt to hash a user's password before storing it in the database, or, in the case of the login page, to hash the entered password before comparing it to the version stored in the database.
Since the login page is the simplest, I focused on it for testing. I repeatedly logged in, and found that it would hang maybe 4 out of 10 times.
As an experiment, I changed the login page to use the plain text password and changed my password in the database to its plain text version. The page stopped hanging.
I saw that PHP's latest version lists this bugfix:
Fixed bug #51059 (crypt crashes when
invalid salt are [sic] given).
So I created a very simple test script, as follows, using the same salt given in an official example:
$foo = crypt('rasmuslerdorf','r1');
echo $foo;
This page, too, will hang, if I reload it like crazy. I only see it hanging in Chrome, but regardless of browser, the effect on Apache is the same.
Effect on Apache
When these pages hang, Apache's server-status page (which I explained here, regarding a different problem) increments the number of requests being processed and decrements the number of idle workers. The requests being processed almost all have a status of 'Sending Reply,' though sometimes for a moment they will show either 'Reading request' or 'keepalive (read).'
Eventually, Apache may crash. When it does, the Windows crash report looks like this:
szAppName: httpd.exe
szAppVer: 2.2.14.0
szModName: php5ts.dll
szModVer: 5.3.1.0 // OK, this report was before I upgraded to PHP 5.3.2,
// but that didn't fix it
offset: 00a2615
Is it my fault?
I'm tempted to file a bug report to PHP on this. The argument against it is, as stated above, that bugs are nearly always my fault.
However, my argument in favor of 'it's PHP's fault' is:
I'm using Windows, whereas most servers use Linux (I don't get to choose this), so the chances are greater that I've found an edge case
There was recently a bug with crypt(), so maybe it still has issues
I have made the simplest test case I can, and I still have the problem
Can anyone duplicate this? Can you suggest where I've gone wrong? Should I file the bug after all?
Thanks in advance for any help you may give.
The bugs 51059 (only about passing invalid inputs) or 50947 (not the same code, 5.3 has new algorithms and features implemented in php, on all platforms) are not related to this problem.
However http://bugs.php.net/bug.php?id=51424 is. I already posted a partial patch there, but it solves most of the possible locks but it is indeed not sufficient. A full fix will be present in the next 5.3 release.
By the way, it is not windows specific but about the threaded SAPI (windows apache 2.2 for example).
This question has now been viewed 128 times and upvoted 9 times. The only answer I've received says it's a bug, and points to one in the PHP bug database. I don't think it's exactly the same one, but it does seem to validate my diagnosis.
Therefore, with some hesitation, I have filed a bug report:
Bug #51666 - Using crypt() makes Apache hang or crash
Thanks to everyone who has looked at this with me - even if you didn't reply, just knowing that others were considering this with me, and not telling me I'm crazy, has been helpful.
Yes. It's a known bug,
http://bugs.php.net/bug.php?id=50947
You can simulate the crypt() result using mcrypt. If you can change your password hash, you should really use hash_hmac(), which is more secure and we have no issues with it On Apache. No experiences on Windows though.