Summary: Application developed on PHP Symfony 1.4.8 loses symfony session values randomly but exclusively on specific production environment: array symfony/user/sfUser/attributes gets empty within seconds or minutes after user authentication. Issue doesn't occur on development machine or at any other production environment.
It seems to be clear the issue is specific to the failing server, However, I wonder if could there be any PHP / Apache / Symfony configuration I might be missing that could solve the issue at the failing server?
Failing Server PHP Info:
PHP Version 5.3.10
System SunOS 5.10
Apache/1.3.41 (Unix) PHP/5.3.10 mod_ssl/2.8.31 OpenSSL/0.9.8p
Max Requests Per Child: 0 - Keep Alive: on - Max Per Connection: 100
Timeouts Connection: 300 - Keep-Alive: 15
Session Support: enabled
Registered save handlers: files user sqlite
Registered serializer handlers: php php_binary
session.cache_expire: 180
session.cache_limiter: nocache
session.cookie_lifetime: 0
session.gc_divisor: 100
session.gc_maxlifetime: 1440
session.gc_probability: 1
session.use_cookies: On
session.use_only_cookies: On
Working Server PHP Info:
PHP Version 5.2.17
System Linux 2.6.32.59-sg2 #3 SMP
Apache/1.3.42 (Unix) mod_gzip/1.3.26.1a mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.8e-fips-rhel5
Session Support: enabled
Registered save handlers: files user sqlite memcache
Registered serializer handlers: php php_binary wddx
session.cache_expire: 180
session.cache_limiter: nocache
session.cookie_lifetime: 0
session.gc_divisor: 1000
session.gc_maxlifetime: 1440
session.gc_probability: 1
session.use_cookies: On
session.use_only_cookies: Off
Symfony Session Settings for both servers at All environments:
storage:
class: sfSessionStorage
param:
session_name: webapp
user:
class: myUser
param:
timeout: 7200
I have already checked over this similar issue Symfony 1.4 sessions randomly lost, however I am not using the sfMemcacheCache class.
Let me know if you might need any extra info to answer this question.
This is probably an obvious thing to check, but maybe the server's out of disk space?
The default session store is file-based, so if you're losing data at random it sound like you're having some hard drive/file system issues.
If you're still curious, you can try changing the location where sessions are stored to another location, hopefully on a different disk.
You probably need to set following settings in your factories.yml file as :
storage:
class: sfSessionStorage
param:
session_name: webapp
session_cookie_lifetime: 2678400 # number of seconds for 1 month
& then remove your cache & reload the website and your SESSION COOKIE will stay active for 1 month.
Related
I have a multipart file upload in a form with a php backend. I've set max_execution_time and max_input_time in php.ini to 180 and confirmed on the file upload that these values are set and set TimeOut 180 in Apache. I've also set
RewriteRule .* - [E=noabort:1]
RewriteRule .* - [E=noconntimeout:1]
When I upload a 250MB file on a fast connection it works fine. When I'm on a slower connection or a network link conditioner to artificially slow it down, the same file times out and on Chrome gives me net::ERR_CONNECTION_RESET after 1 minute (and 5 seconds) reliably. I've also tried other browsers with the same outcome, just different error messages.
There is no indication to an error in any log and I've tried both on http and https.
What would cause the upload connection to be reset after 1 minute?
EDIT
I've now also tried to have a simple upload form that bypasses any framework I'm using, still timeouts at 1 minute.
I've also just made a sleep script that timeouts after 2 and a half minutes, and that works, page takes around 2.5 minutes to load so I can't see how it's browser or header related.
I've also used a server with more RAM to ensure it's not related to that. I've tested on 3 different servers with different specs but all from the same CentOS 7 base.
I've now also upgraded to PHP 7.2 and updated the relevant fields again with no change in the problem.
EDIT 2
The tech stack for this isolated instance is
Apache 2.4.6
PHP 5.6 / 7.2 (tried both), has OPCache
Redis 3.2.6 for session information and key / value storage (ElastiCache)
PostgreSQL 10.2 (RDS)
Everything else in my tech stack has been removed from this test area to try and isolate the problem. EFS is on the system but in my most isolated test it's just using EBS.
EDIT 3
Here some logs from the chrome network debugger:
{"params":{"net_error":-101,"os_error":32},"phase":0,"source": {"id":274043,"type":8},"time":"3332701830","type":69},
{"params": {"error_lib":33,"error_reason":101,"file":"../../net/socket/socket_bio_adapter.cc","line":216,"net_error":-101,"ssl_error":1},"phase":0,"source": {"id":274043,"type":8},"time":"3332701830","type":56},
{"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":159},
{"phase":1,"source": {"id":274038,"type":1},"time":"3332701830","type":164},
{"phase":1,"source": {"id":274038,"type":1},"time":"3332701830","type":287},
{"params": {"error_lib":33,"error_reason":101,"file":"../../net/socket/socket_bio_adapter.cc","line":113,"net_error":-101,"ssl_error":1},"phase":0,"source": {"id":274043,"type":8},"time":"3332701830","type":55},
{"params":{"net_error":-101},"phase":2,"source": {"id":274038,"type":1},"time":"3332701830","type":287},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":164},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":97},
{"phase":1,"source":{"id":274038,"type":1},"time":"3332701830","type":105},
{"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":105},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":38},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":38},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":34},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":2},
I went through a similar problem, in my case it was related to mod_reqtimeout by adding:
RequestReadTimeout header=20-40, MinRate=500 body=20, MinRate=500
to httpd.conf did the trick!
You can check the documentation here.
Hope it helps!
Original source here
ERR_CONNECTION_RESET usually means that the connection to the server has ceased without sending any response to the client. This means that the entire PHP process has died without being able to shut down properly.
This is usually not caused by something like an exceeded memory_limit. It could be some sort of Segmentation Fault or something like that. If you have access to error logs, check them. Otherwise, you might get support from your hosting company.
I would recommend you to try some of these things:
Try cleaning the browser's cache. If you have already visited the page, it is possible for the cache to contain information that doesn’t match the current version of the website and so blocks the connection setup, making the ERR_CONNECTION_RESET message appear.
Add the following to your settings:
memory_limit = 1024M
max_input_vars = 2000
upload_max_filesize = 300M
post_max_size = 300M
max_execution_time = 990
Try setting the following input in your form:
In your processing script, increase the session timeout:
set_time_limit(200);
You might need to tune up the SSL buffer size in your apache config file.
SSLRenegBufferSize 10486000
The name and location of the conf file is different depending on distributions.
In Debian you find the conf file in /etc/apache2/sites-available/default-ssl.conf
A few times it is mod_security module which prevents post of large data approximately 171 KB. Try adding/modifying the following in mod_security.conf
SecRequestBodyNoFilesLimit 10486000
SecRequestBodyInMemoryLimit 10486000
I hope something might work out!
Incase anybody else runs into this - there is also a problem with this relating to PHP-FPM. If you dont set "ProxyTimeout" in your httpd.conf - PHP-FPM uses a default timeout of one minute. It took me several hours to figure out the problem as I initially was thinking of all the normal settings like everyone else.
I had the same problem. I used the resumable file upload method where if the internet is disconnected and reconnects back then the upload resumes from the same progress.
Check out the library https://packagist.org/packages/pion/laravel-chunk-upload
Installation
composer require pion/laravel-chunk-upload
Add service provider
\Pion\Laravel\ChunkUpload\Providers\ChunkUploadServiceProvider::class
Publish the config
php artisan vendor:publish --provider="Pion\Laravel\ChunkUpload\Providers\ChunkUploadServiceProvider"
In my opinion it maybe relative to one of them:
About apache config (/etc/httpd2/conf ou /etc/apache2/conf):
Timeout 300
max_execution_time = 300
About php config ('php.ini'):
upload_max_filesize = 2000M
post_max_size = 2000M
max_input_time = 300
memory_limit = 3092M
max_execution_time = 300
About PostgreSQL config (execute this request):
SET statement_timeout TO 0;
About proxy, (or apache mod_proxy), it maybe also be due to proxy timeout configuration
in case anyone has the same issue, the problem I encountered is that the http request has to go through proxy sever and waf, small files upload is ok, but with large files the tcp connection automatically closed, how to validate:
simply change your hosts setting point the domain to the web server ip address (or you may use firefox with no-proxy if there is no waf), if your problem gone then it's the caused by the proxy or the waf in between your web server and the browser
Connection-Reset occurs when php process dies without proper error message.
Changing oracle client version from 19 to 12c and then appropriately configuring in php.ini solved the connection reset issue for our team.
we are deploying a PHP script on AWS elastic beanstalk and found it's take a lot of time compare with normal servers
even on empty PHP files with no code to run it's take about 128 ms form google chrome TTFB
google chrome ttfb screenshot
is this normal? and if not normal why ? and what to do to make it faster
my environment config is :
Environment type: Load balanced, auto scaling
Number instances: 2 - 4
Scale based on Average network out
Add instance when > 6000000
Remove instance when < 2000000
Instance type: t2.micro
Root volume type: Magnetic
Root volume size: 10 GiB
Availability Zones: Any
and .elasticbeanstalk contents is :
config.yml
branch-defaults:
default:
environment: Development
global:
application_name: testing
default_ec2_keyname: testing
default_platform: 64bit Amazon Linux 2016.03 v2.1.4 running PHP 5.6
default_region: eu-central-1
profile: eb-cli
sc: null
I have a symfony2 project with a page to write the report of a meeting. It means the user can stay on this page and type for 2 hours without loading any new page. So when the user sends the form, his session has expired and he is sent to the login page. And he loses everything he typed.
I've already seen this post "symfony2 session lifetime" so here is my config.yml :
framework:
session:
handler_id: ~
cookie_lifetime: 86400
gc_maxlifetime: 108000
So a 24 hours cookie lifetime and a 30 hour garbage collector... Still, I tried staying 1 hour on the page and I am disconnected...
Any idea where to look at ? Thanks !
So, it looks like changing symfony's config.yml doesn't work. But after modifying the gc_maxlifetime to 108000 in my php.ini it works, I am not disconnected after some idle time.
I guess this might be linked to the handler_id: ~ (which is default), but I don't really know why... Anyway, works this way :)
Try these settings:
framework:
session:
cookie_lifetime: 60 #60 seconds
gc_maxlifetime: 50 #50 seconds - only needed for testing. Dont use this in a production environment
gc_probability: 1 #only needed for testing. Dont use this in a production environment
gc_divisor: 1 #only needed for testing. Dont use this in a production environment
You can see them over here: https://codedump.io/share/9eVPS5otSIuk
My Symfony2 application displays a main page, and from there on it primarily uses AJAX requests to display content to the user via modals.
I've noticed that after the user is idle for some period of time (around 15-30 minutes) the session is destroyed, and the user is logged out and needs to log in again. This is incredibly frustrating, since I can't expect users to log in again every time they've been idle for a few minutes.
As far as I can tell, this problem should not be happening according to my config.yml file, which is as follows:
framework:
session:
cookie_lifetime: 0 # Session lifetime in seconds
gc_maxlifetime: 28800 # Seconds after which data will be seen
# as garbage and potentially cleaned up
handler_id: ~ # Current using the default session handler
For completeness, my current environment is as follows:
Symfony 2.4.8
PHP 5.4
Session handler: default (file-based according to php.ini)
Ubuntu Server 12.10
Summary:
What should be happening: users should not be logged out, even after being idle for hours
What is actually happening: users are being logged out after being idle for 15-30 minutes
How can I fix this?
The problem:
It turns out that on Debian / Ubuntu systems, there is a system cronjob which runs every 30 minutes, cleaning out all "old" sessions. Herein lies the problem.
The cronjob doesn't actually know what constitutes "old". The cronjob simply calls a PHP-CLI script located at /usr/lib/php5/maxlifetime which then removes all session files that exceed a certain age. Since the script is involved by PHP-CLI, and independently of Symfony2, it has no idea what values you specified for gc_maxlifetime and cookie_lifetime in your Symfony2 config file. Instead, if just defaults to using the session.cookie_lifetime and session.gc_maxlifetime values from the /etc/php5/cli/php.ini config file, which by default, is 24 minutes. So no matter what you specify in your Symfony2 config file, if you are idle for too long, your session will be removed.
The solution:
Either delete the cronjob file at /etc/cron.d/php5 or,
Store your sessions in a database where they can't be touched by the cronjob
I set remember me cookie set to default, and then in security.yml
security:
firewalls:
main:
form_login:
remember_me: true
remember_me:
key: mycookie
lifetime: 2592000 # 30 days
path: /
domain: ~
always_remember_me: true
My first answer seems not suitable for your issue. Maybe this one will help.
Do you clear Symfony cache between your requests ?
Extract of symfony documentation :
save_path
type: string default: %kernel.cache.dir%/sessions
This determines the argument to be passed to the save handler. If you
choose the default file handler, this is the path where the session
files are created. For more information, see Configuring the Directory
where Session Files are Saved.
You can also set this value to the save_path of your php.ini by setting the value to null.
By default, Symfony stores sessions in the cache directory that is emptied while clearing cache...
Extract of symfony documentation :
cookie_lifetime
type: integer default: null
This determines the lifetime of the session - in seconds. It will use
null by default, which means session.cookie_lifetime value from
php.ini will be used. Setting this value to 0 means the cookie is
valid for the length of the browser session.
So, 0 is not infinite session BUT browser session... You should define a big amoutn of seconds and test it.
Travis T, I went the simplest route of all. I said
nano /etc/cron.d/php5
This opened the file showing the tremendously long crontab code that purges your session by default every 30 mins. The script was preceded by a #, and all I did was uncomment both lines by removing the #. So:
# Look for and purge old sessions every 30 minutes
# 09, 39, * * * * root #[ -x /usr/lib/php5/maxlifetime ] && [ etc
it's a long file.....]
I just removed the 2 #'s in front of Look and 09. That's it !
Here's my situation: I have a website built with CakePHP and MySQL. My website has a public forum where members can post code samples. Some of these code samples are going to include PHP and MySQL code.
I understand that this is probably a dangerous thing to allow, but for one: Only members whom I have specifically "approved" may post, and two: I believe CakePHP already uses parameterized queries... and while I'm sure there are still other risks involved, that is not what my question is concerned with.
The problem:
In my local testing environment, I can submit posts that include SQL statements and strings with php code like <?php phpinfo(); ?>; but, when running the exact same code on my production server, I can't.
Rather than being redirected to /posts/index (which is what normally happens after posting), I am redirected back to the same page I was on before (/posts/edit/25, for example). It seems that when I attempt to submit form data that includes "illegal" substrings, the submittal silently fails, and CakePHP just sends me back to where I was before. (No flash messages on CakePHP's behalf.)
My diagnosis thus far:
CakePHP's /www/app/tmp/logs/error.log shows no sign of an error after I attempt to post this data. I don't have access to any other server log files at the moment.
I tried removing some of the php code from my posts. I was able to submit strings like <?php echo 'Hello World'; ?>, but if a function like phpinfo() was anywhere in the form data, the post would get "rejected". Stuffing my SQL examples with non-breaking-spaces also made it possible for me to submit form data that included SQL statements.
The MySQL user account that CakePHP uses is a little restricted. I forget exactly which actions it is allowed to perform, but I think they are just select, insert, update, delete, create, drop, and maybe a few others.
However, I also use phpMyAdmin locally to manage the production database, and when I access it via phpMyAdmin, I am using an admin account with maximum privileges. And when I manually change data through phpMyAdmin, strings like phpinfo(); in my code examples don't get rejected!
Even though this seemed like a small glimmer of hope, I have tested my site with CakePHP setup to use the MySQL admin user with max privileges, but I still can't submit my unsafe strings via the user-facing form.
My unsatisfying conclusion thus far:
Since the exact same php code behaves differently depending on my environment, I suspect this has something do with my PHP version, MySQL version, or some security measure my sysadmin has put in place.
My sysadmin is rather hard to get in touch with though, so I'm trying to figure what might be causing the problem on my own.
My question:
What might my problem be? Is there a PHP setting that prohibits "unsafe" strings, or some other commonly-known setting that I could request my sysadmin to change? Or perhaps might this be a MySQL setting? (Hard to tell given my phpMyAdmin's strange ability to do things that Cake can't.) Or how might I go about diagnosing this problem? (On my own; or, what kind of question I should ask my sysadmin?)
More data that might be of use:
So, this is my local testing environment according to phpMyAdmin:
Database server
---------------
Server: Local codeTech Server (Localhost via UNIX socket)
Server type: MySQL
Server version: 5.5.34-0ubuntu0.13.04.1 - (Ubuntu)
Protocol version: 10
User: root#localhost
Server charset: UTF-8 Unicode (utf8)
Web server
----------
Apache/2.2.22 (Ubuntu)
Database client version: libmysql - 5.5.34
PHP extension: mysqli
And here is my production server's environment:
Database server
---------------
Server: Sam's Remote Server (XXX.XXX.XXX.XXX via TCP/IP)
Server type: MySQL
Server version: 5.1.70-cll - MySQL Community Server (GPL)
Protocol version: 10
User: XXX#XXX.com
Server charset: UTF-8 Unicode (utf8)
Web server
----------
Apache/2.2.22 (Ubuntu)
Database client version: libmysql - 5.5.34
PHP extension: mysqli
I'd also be willing to post some portions of phpinfo for both servers, if that would help.
A few things I gleamed from phpinfo that may help diagnose the problem:
Local:
PHP Version 5.4.9-4ubuntu2.3
Zend Engine v2.4.0
Production:
PHP Version 5.3.26
Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies
with the ionCube PHP Loader v4.2.2, Copyright (c) 2002-2012, by ionCube Ltd., and
with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH
This server is protected with the Suhosin Extension 0.9.33
I suspect that this "Suhosin" extension might have something to do with it, though I'm not quite sure how...
Their page (http://www.hardened-php.net/suhosin/a_feature_list.html) suggests there may be a few "protections" in place:
Transparent protection of open phpinfo() pages
EXPERIMENTAL SQL
database user protection
Filtering Features
Configureable action on violation
just block violating variables
send HTTP response code
redirect the browser
In fact, this sounds highly suspect! I will probably have to have a talk with my sysadmin about this thing; unfortunately, the documentation on Suhosin is too sparse for me to know if it is actually the culprit, so I don't want to rule out everything else just yet.
Still, it might be important. These are the settings for Suhosin; they don't really make much sense to me, but maybe some PHP wizards can highlight some important keywords:
Directive Local Value Master Value
suhosin.apc_bug_workaround Off Off
suhosin.cookie.checkraddr 0 0
suhosin.cookie.cryptdocroot On On
suhosin.cookie.cryptkey [ protected ] [ protected ]
suhosin.cookie.cryptlist no value no value
suhosin.cookie.cryptraddr 0 0
suhosin.cookie.cryptua On On
suhosin.cookie.disallow_nul 1 1
suhosin.cookie.disallow_ws 1 1
suhosin.cookie.encrypt Off Off
suhosin.cookie.max_array_depth 50 50
suhosin.cookie.max_array_index_length 64 64
suhosin.cookie.max_name_length 64 64
suhosin.cookie.max_totalname_length 256 256
suhosin.cookie.max_value_length 10000 10000
suhosin.cookie.max_vars 100 100
suhosin.cookie.plainlist no value no value
suhosin.coredump Off Off
suhosin.disable.display_errors Off Off
suhosin.executor.allow_symlink Off Off
suhosin.executor.disable_emodifier Off Off
suhosin.executor.disable_eval Off Off
suhosin.executor.eval.blacklist no value no value
suhosin.executor.eval.whitelist no value no value
suhosin.executor.func.blacklist no value no value
suhosin.executor.func.whitelist no value no value
suhosin.executor.include.allow_writable_files On On
suhosin.executor.include.blacklist no value no value
suhosin.executor.include.max_traversal 0 0
suhosin.executor.include.whitelist no value no value
suhosin.executor.max_depth 0 0
suhosin.filter.action no value no value
suhosin.get.disallow_nul 1 1
suhosin.get.disallow_ws 0 0
suhosin.get.max_array_depth 50 50
suhosin.get.max_array_index_length 64 64
suhosin.get.max_name_length 64 64
suhosin.get.max_totalname_length 256 256
suhosin.get.max_value_length 512 512
suhosin.get.max_vars 100 100
suhosin.log.file 0 0
suhosin.log.file.name no value no value
suhosin.log.phpscript 0 0
suhosin.log.phpscript.is_safe Off Off
suhosin.log.phpscript.name no value no value
suhosin.log.sapi 0 0
suhosin.log.script 0 0
suhosin.log.script.name no value no value
suhosin.log.syslog no value no value
suhosin.log.syslog.facility no value no value
suhosin.log.syslog.priority no value no value
suhosin.log.use-x-forwarded-for Off Off
suhosin.mail.protect 0 0
suhosin.memory_limit 0 0
suhosin.mt_srand.ignore On On
suhosin.multiheader Off Off
suhosin.perdir 0 0
suhosin.post.disallow_nul 1 1
suhosin.post.disallow_ws 0 0
suhosin.post.max_array_depth 50 50
suhosin.post.max_array_index_length 64 64
suhosin.post.max_name_length 64 64
suhosin.post.max_totalname_length 256 256
suhosin.post.max_value_length 1000000 1000000
suhosin.post.max_vars 1000 1000
suhosin.protectkey On On
suhosin.request.disallow_nul 1 1
suhosin.request.disallow_ws 0 0
suhosin.request.max_array_depth 50 50
suhosin.request.max_array_index_length 64 64
suhosin.request.max_totalname_length 256 256
suhosin.request.max_value_length 1000000 1000000
suhosin.request.max_varname_length 64 64
suhosin.request.max_vars 1000 1000
suhosin.server.encode On On
suhosin.server.strip On On
suhosin.session.checkraddr 0 0
suhosin.session.cryptdocroot On On
suhosin.session.cryptkey [ protected ] [ protected ]
suhosin.session.cryptraddr 0 0
suhosin.session.cryptua Off Off
suhosin.session.encrypt On On
suhosin.session.max_id_length 128 128
suhosin.simulation Off Off
suhosin.sql.bailout_on_error Off Off
suhosin.sql.comment 0 0
suhosin.sql.multiselect 0 0
suhosin.sql.opencomment 0 0
suhosin.sql.union 0 0
suhosin.sql.user_postfix no value no value
suhosin.sql.user_prefix no value no value
suhosin.srand.ignore On On
suhosin.stealth On On
suhosin.upload.disallow_binary 0 0
suhosin.upload.disallow_elf 1 1
suhosin.upload.max_uploads 25 25
suhosin.upload.remove_binary 0 0
suhosin.upload.verification_script no value no value
Thanks in advance to anyone who can help me troubleshoot this. And congrats on reading this far!
About your PHP configuration differences between environments, you should compare the results of a phpinfo() execution in devel and production environments. Depending on the version, you can have magic_quotes activated (BAD IDEA!) or other configurations affecting your code, just compare one by one and you'll get the differences, which you should eliminate in almost all cases (except display_errors and a few more that need to be different in production and development).
About MySQL: you need to have two different users, which you will use depending on the query:
1) One for reading, with just SELECT permissions
2) The other for writing, with SELECT, UPDATE, DELETE, INSERT (normally, CREATE and DROP are NOT necessary in a website and are a focus of possible security exploits)
Normally, you will use the "reading" user and you just change to "write" for the specific queries that need to write.
I don't think your problem is in PHP (but check the phpinfo) and positively is not in MySQL, my bet would be the Suhosin plugin and, maybe, a configuration in CakePHP that changes depending on your environment, but with the given information, I can tell no more.
I never heard about Suhosin and if I were you, my first step would be to deactivate it. Using PDO's binding funcions and php filters will be a secure option without extra plugins.