php-general Digest 3 Aug 2013 09:32:30 -0000 Issue 8319
php-general Digest 3 Aug 2013 09:32:30 - Issue 8319 Topics (messages 321772 through 321777): Re: OT - Internet Troubles?⦠321772 by: Bastien 321773 by: Daniel suhosin and 5.4 onwards 321774 by: Nick Edwards 321775 by: Daniel 321776 by: Lester Caine 321777 by: Res Administrivia: To subscribe to the digest, e-mail: php-general-digest-subscr...@lists.php.net To unsubscribe from the digest, e-mail: php-general-digest-unsubscr...@lists.php.net To post to the list, e-mail: php-gene...@lists.php.net -- ---BeginMessage--- It's just the NSA doing an update. I wonder what they charge for cloud backups? Bastien Koert On 2013-08-02, at 3:37 PM, dealTek deal...@gmail.com wrote: OT Anyone having internet troubles? (also seems to be login database issues too at various places) like... http://forums.adobe.com/community/dreamweaver and try to sign in on upper right i get this We're sorry, the site area you've requested is unavailable. Please try again later. and - go to - http://bluehost.com and try LIVE CHAT in mid page and it also fails... i get Our chat service is currently undergoing maintenance and will be back online shortly. Call us (888) 401-4678 or open a ticket if you need further assistance. and other issues too like also http://www.downdetector.com/status/time-warner-cable/los-angeles Time Warner Cable Los Angeles reports ugh! #twc #timewarnercable connectivity issues again, and apparently it's effecting a lot of work from home coworkers..get it fixed!! — (@BloodBought3) 2013-08-02 07:37:59 -- Thanks, Dave - DealTek deal...@gmail.com [db-3] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ---End Message--- ---BeginMessage--- LMAO, no there a big data centre outage: http://enduranceresponse.com/ On Sat, Aug 3, 2013 at 11:53 AM, Bastien phps...@gmail.com wrote: It's just the NSA doing an update. I wonder what they charge for cloud backups? Bastien Koert On 2013-08-02, at 3:37 PM, dealTek deal...@gmail.com wrote: OT Anyone having internet troubles? (also seems to be login database issues too at various places) like... http://forums.adobe.com/community/dreamweaver and try to sign in on upper right i get this We're sorry, the site area you've requested is unavailable. Please try again later. and - go to - http://bluehost.com and try LIVE CHAT in mid page and it also fails... i get Our chat service is currently undergoing maintenance and will be back online shortly. Call us (888) 401-4678 or open a ticket if you need further assistance. and other issues too like also http://www.downdetector.com/status/time-warner-cable/los-angeles Time Warner Cable Los Angeles reports ugh! #twc #timewarnercable connectivity issues again, and apparently it's effecting a lot of work from home coworkers..get it fixed!! — (@BloodBought3) 2013-08-02 07:37:59 -- Thanks, Dave - DealTek deal...@gmail.com [db-3] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ---End Message--- ---BeginMessage--- Ok, so I know this might start flame wars, but... here goes ;) It seems suhosin is dead as far as 5.4 goes, now, some make allegations that it is no longer needed since php has allegedly incorporated much of its safe guards, but these claims are from self proclaimed experts (a term i use very loosley) on forums and blogs. So, is the general opinion here, from actual factual experience and not because you read the same trashy bloggers as I did, in agreeance? is it genuinely true that suhosin is now irrelevant with 5.4 upwards and php is now much safer on its own? We have always appreciated its work to stop plugins and so forth escaping local jails by example open_base or some other lock-down type setting, plus injections and so forth. if php has incorporated such, thats fine, but I have no idea where to turn to ask for factual information on this, so I'm asking here and hope that a dev or someone in the inner circle knows the facts, and not rumours or sumizes, or a tleast more facts than half the self appointed gurus claim :) Thanks Nikki ---End Message--- ---BeginMessage--- Well I do not use suhosin as I can lock down PHP with things like disable_function, disable_classes along with more advance function such as chroot and mod_security. On 8/3/13, Nick Edwards nick.z.edwa...@gmail.com wrote: Ok, so I know this might start flame wars, but... here goes ;) It seems suhosin is dead as far as 5.4 goes, now, some make allegations that it is no longer needed since php has allegedly
php-general Digest 3 Aug 2013 21:47:14 -0000 Issue 8320
php-general Digest 3 Aug 2013 21:47:14 - Issue 8320 Topics (messages 321778 through 321781): Re: Sending headers to server 321778 by: Karim Geiger 321781 by: Matijn Woudt Session Vars not staying active 321779 by: dealTek 321780 by: Daniel P. Brown Administrivia: To subscribe to the digest, e-mail: php-general-digest-subscr...@lists.php.net To unsubscribe from the digest, e-mail: php-general-digest-unsubscr...@lists.php.net To post to the list, e-mail: php-gene...@lists.php.net -- ---BeginMessage--- Am 02.08.13 18:03, schrieb Miguel Guedes: This is strange. I've just found out that the headers are sent correctly if I access the website outside of localhost. I don't understand why. I also don't. I've tried the exactly same code you posted on my localhost as well and it worked all properly. Weird behaviour, can anyone explain why this happens? Regards Karim -- Karim Geiger Auszubildender Fachinformatiker AE B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature ---End Message--- ---BeginMessage--- On Sat, Aug 3, 2013 at 11:46 AM, Karim Geiger gei...@b1-systems.de wrote: Am 02.08.13 18:03, schrieb Miguel Guedes: This is strange. I've just found out that the headers are sent correctly if I access the website outside of localhost. I don't understand why. I also don't. I've tried the exactly same code you posted on my localhost as well and it worked all properly. Weird behaviour, can anyone explain why this happens? Regards Karim Could it be that you're actually ending up with a different site because you have configured your vhost to a certain domain? - Matijn ---End Message--- ---BeginMessage--- Hi all, I am having trouble with session vars. I'm trying to implement the credit card direct pay method outlined here... http://developer.authorize.net/api/dpm/ - Basically, page 1 is my form that goes outside my site to the cc gateway company then comes back with a result... (PG2) Problem: if I try to create session vars on page 1 - they don't work on page 2. Am I correct in thinking that when this process leaves my site and goes to the gateway, then returns, it is similar to creating a new session and that is why the session vars don't remain active? Thanks in advance. -- Thanks, Dave - DealTek deal...@gmail.com [db-3] ---End Message--- ---BeginMessage--- On Aug 3, 2013 3:03 PM, dealTek deal...@gmail.com wrote: Hi all, I am having trouble with session vars. I'm trying to implement the credit card direct pay method outlined here... http://developer.authorize.net/api/dpm/ - Basically, page 1 is my form that goes outside my site to the cc gateway company then comes back with a result... (PG2) Problem: if I try to create session vars on page 1 - they don't work on page 2. Am I correct in thinking that when this process leaves my site and goes to the gateway, then returns, it is similar to creating a new session and that is why the session vars don't remain active? Thanks in advance. Are you calling session_start() on both pages or at least using a session auto start? Also, is the API returning the data by redirecting the client (browser) or doing a postback? If the remote server is calling back behind the scenes, then you'll need a workaround and additional processing, or the ability to pass the session ID and assume the client-initiated session (not ideal). If it's all processed by the browser, the redirection should have no bearing, as the session will persist based upon the server-side data and the client-side cookie; the server will have no knowledge of the client's redirection to the payment gateway (nor any remote destination). ---End Message---
[PHP] suhosin and 5.4 onwards
Ok, so I know this might start flame wars, but... here goes ;) It seems suhosin is dead as far as 5.4 goes, now, some make allegations that it is no longer needed since php has allegedly incorporated much of its safe guards, but these claims are from self proclaimed experts (a term i use very loosley) on forums and blogs. So, is the general opinion here, from actual factual experience and not because you read the same trashy bloggers as I did, in agreeance? is it genuinely true that suhosin is now irrelevant with 5.4 upwards and php is now much safer on its own? We have always appreciated its work to stop plugins and so forth escaping local jails by example open_base or some other lock-down type setting, plus injections and so forth. if php has incorporated such, thats fine, but I have no idea where to turn to ask for factual information on this, so I'm asking here and hope that a dev or someone in the inner circle knows the facts, and not rumours or sumizes, or a tleast more facts than half the self appointed gurus claim :) Thanks Nikki -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] suhosin and 5.4 onwards
Well I do not use suhosin as I can lock down PHP with things like disable_function, disable_classes along with more advance function such as chroot and mod_security. On 8/3/13, Nick Edwards nick.z.edwa...@gmail.com wrote: Ok, so I know this might start flame wars, but... here goes ;) It seems suhosin is dead as far as 5.4 goes, now, some make allegations that it is no longer needed since php has allegedly incorporated much of its safe guards, but these claims are from self proclaimed experts (a term i use very loosley) on forums and blogs. So, is the general opinion here, from actual factual experience and not because you read the same trashy bloggers as I did, in agreeance? is it genuinely true that suhosin is now irrelevant with 5.4 upwards and php is now much safer on its own? We have always appreciated its work to stop plugins and so forth escaping local jails by example open_base or some other lock-down type setting, plus injections and so forth. if php has incorporated such, thats fine, but I have no idea where to turn to ask for factual information on this, so I'm asking here and hope that a dev or someone in the inner circle knows the facts, and not rumours or sumizes, or a tleast more facts than half the self appointed gurus claim :) Thanks Nikki -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Daniel Fenn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] suhosin and 5.4 onwards
Nick Edwards wrote: So, is the general opinion here, from actual factual experience and not because you read the same trashy bloggers as I did, in agreeance? is it genuinely true that suhosin is now irrelevant with 5.4 upwards and php is now much safer on its own? Practical experience is that suhosin does not actually work with 5.4? I've had to disable it because of problems with session handling amongst other things and don't have time to investigate why. Would I prefer to re-enable it - YES - and it's one of a number of reasons that have been making switching currently stable PHP5.2 servers over to 5.4 less attractive. The amount of time I'm wasting on coping with many of the so called improvements across the whole Linux platform is making me feel that commercial interests are actually in control rather than users/developers? Staying with stable platforms that we are comfortable with is just not practical :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] suhosin and 5.4 onwards
On 03/08/2013 18:50, Lester Caine wrote:
Practical experience is that suhosin does not actually work with 5.4?
Not without _unofficial_ patch(es) see attached for sessions, if it
doesnt go through on list you can find the patch on github
I've had to disable it because of problems with session handling
amongst other
things and don't have time to investigate why.
There was a patch on suhosin mailing list for that, a few people who
tried it out said it worked. I've not yet bothered, but...
I saw a post from Steffen saying he has no time for suhosin and the
project is being taken over by someone else, I think the jury is out on
if it will ever revive, in meantime, php 5.3 works fine. if only php
devs would stop fscking changing everything every time they release a
new version, frustrating to many.
And people who reply on mod_security are no more protected than what is
being done here, since mod_security has not had the best track record
itself in the past.
Would I prefer to re-enable it - YES - and it's one of a number of
reasons that
have been making switching currently stable PHP5.2 servers over to 5.4
less
attractive.
The amount of time I'm wasting on coping with many of the so called
improvements
across the whole Linux platform is making me feel that commercial
interests are
Thats why I recommend distros that dont want to change the world and
stick by tried and time proven, like slackware and gentoo, but this isnt
an os flame against others, I use opensuse as well on pc's and laptops.
Everything just looks after itself :)
From 117b6aa6efec61afaa1431c698dad8eb553b55f5 Mon Sep 17 00:00:00 2001
From: Olivier Blin d...@blino.org
Date: Sun, 31 Mar 2013 01:15:48 +0100
Subject: [PATCH] Fix saving sessions in PHP 5.4 with user session handlers
(fix #12)
When session storage functions are set with session_set_save_handler()
(this is the mod_user mode), mod_data will be NULL in PHP 5.4, and
suhosin session hooks will bail out.
PHP 5.4 allows to check this with mod_user_implemented instead.
---
session.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/session.c b/session.c
index 1045a93..513c195 100644
--- a/session.c
+++ b/session.c
@@ -728,7 +728,12 @@ static int suhosin_hook_s_read(void **mod_data, const char *key, char **val, int
}*/
/* protect dumb session handlers */
-if (key == NULL || !key[0] || *mod_data == NULL) {
+if (key == NULL || !key[0] ||
+ (*mod_data == NULL
+#if PHP_VERSION_ID = 50400
+ !SESSION_G(mod_user_implemented)
+#endif
+ )) {
regenerate:
SDEBUG(regenerating key is %s, key);
KEY = SESSION_G(id) = SESSION_G(mod)-s_create_sid(SESSION_G(mod_data), NULL TSRMLS_CC);
@@ -777,7 +782,12 @@ static int suhosin_hook_s_write(void **mod_data, const char *key, const char *va
char *v = (char *)val;
/* protect dumb session handlers */
-if (key == NULL || !key[0] || val == NULL || strlen(key) SUHOSIN_G(session_max_id_length) || *mod_data == NULL) {
+if (key == NULL || !key[0] || val == NULL || strlen(key) SUHOSIN_G(session_max_id_length) ||
+ (*mod_data == NULL
+#if PHP_VERSION_ID = 50400
+ !SESSION_G(mod_user_implemented)
+#endif
+ )) {
r = FAILURE;
goto return_write;
}
@@ -820,7 +830,12 @@ static int suhosin_hook_s_destroy(void **mod_data, const char *key TSRMLS_DC)
int r;
/* protect dumb session handlers */
-if (key == NULL || !key[0] || strlen(key) SUHOSIN_G(session_max_id_length) || *mod_data == NULL) {
+if (key == NULL || !key[0] || strlen(key) SUHOSIN_G(session_max_id_length) ||
+ (*mod_data == NULL
+#if PHP_VERSION_ID = 50400
+ !SESSION_G(mod_user_implemented)
+#endif
+ )) {
return FAILURE;
}
--
1.8.1.5
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sending headers to server
Am 02.08.13 18:03, schrieb Miguel Guedes: This is strange. I've just found out that the headers are sent correctly if I access the website outside of localhost. I don't understand why. I also don't. I've tried the exactly same code you posted on my localhost as well and it worked all properly. Weird behaviour, can anyone explain why this happens? Regards Karim -- Karim Geiger Auszubildender Fachinformatiker AE B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
[PHP] Session Vars not staying active
Hi all, I am having trouble with session vars. I'm trying to implement the credit card direct pay method outlined here... http://developer.authorize.net/api/dpm/ - Basically, page 1 is my form that goes outside my site to the cc gateway company then comes back with a result... (PG2) Problem: if I try to create session vars on page 1 - they don't work on page 2. Am I correct in thinking that when this process leaves my site and goes to the gateway, then returns, it is similar to creating a new session and that is why the session vars don't remain active? Thanks in advance. -- Thanks, Dave - DealTek deal...@gmail.com [db-3]
Re: [PHP] Session Vars not staying active
On Aug 3, 2013 3:03 PM, dealTek deal...@gmail.com wrote: Hi all, I am having trouble with session vars. I'm trying to implement the credit card direct pay method outlined here... http://developer.authorize.net/api/dpm/ - Basically, page 1 is my form that goes outside my site to the cc gateway company then comes back with a result... (PG2) Problem: if I try to create session vars on page 1 - they don't work on page 2. Am I correct in thinking that when this process leaves my site and goes to the gateway, then returns, it is similar to creating a new session and that is why the session vars don't remain active? Thanks in advance. Are you calling session_start() on both pages or at least using a session auto start? Also, is the API returning the data by redirecting the client (browser) or doing a postback? If the remote server is calling back behind the scenes, then you'll need a workaround and additional processing, or the ability to pass the session ID and assume the client-initiated session (not ideal). If it's all processed by the browser, the redirection should have no bearing, as the session will persist based upon the server-side data and the client-side cookie; the server will have no knowledge of the client's redirection to the payment gateway (nor any remote destination).
Re: [PHP] Sending headers to server
On Sat, Aug 3, 2013 at 11:46 AM, Karim Geiger gei...@b1-systems.de wrote: Am 02.08.13 18:03, schrieb Miguel Guedes: This is strange. I've just found out that the headers are sent correctly if I access the website outside of localhost. I don't understand why. I also don't. I've tried the exactly same code you posted on my localhost as well and it worked all properly. Weird behaviour, can anyone explain why this happens? Regards Karim Could it be that you're actually ending up with a different site because you have configured your vhost to a certain domain? - Matijn
