php-general Digest 29 May 2007 08:28:36 -0000 Issue 4817
php-general Digest 29 May 2007 08:28:36 - Issue 4817
Topics (messages 255718 through 255740):
Re: php and Ajax problem
255718 by: Stut
255719 by: Tijnema
255736 by: Jim Lucas
Re: Unknown number of check boxes?
255720 by: Jared Farrish
255721 by: Jared Farrish
255738 by: Jim Lucas
Re: Upload a ppt file
255722 by: Tijnema
Tuning LAMP systems: Optimizing Apache and PHP
255723 by: Daevid Vincent
Web Application Design Literature
255724 by: Steve Finkelstein
255726 by: Jared Farrish
exec dont work for svn
255725 by: Manolet Gmail
255735 by: Greg Donald
php execute command on server
255727 by: Jody Gugelhupf
255734 by: Greg Donald
a question on session ID and security
255728 by: Davis Chan
255729 by: Jared Farrish
Client does not support authentication protocol...
255730 by: Tom
255731 by: Chris
255733 by: Chris
255740 by: Zoltán Németh
Streaming download to IE doesn't work
255732 by: Daniel Kasak
Re: Uploading Files into MySQL
255737 by: Greg Donald
Re: Form Validation Issues
255739 by: Greg Donald
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
--
---BeginMessage---
Not even slightly a PHP question, but since it's a bank holiday I seem
to temporarily be in a more helpful mood.
Richard Kurth wrote:
?php
$event['deleteevent']='a
href=javascript:sendRequest(delete,32423434234234234324)Delete this
event/a';
echo $event['deleteevent'];
?
I'm thinking you need some quotes aroung delete, and possibly around the
number given its size.
-Stut
---End Message---
---BeginMessage---
On 5/28/07, Richard Kurth [EMAIL PROTECTED] wrote:
I can not figure out way this is not working can somebody help?
html
head
titleUntitled/title
script language=JavaScript
function createRequestObject() {
var req;
if(window.XMLHttpRequest){
// Firefox, Safari, Opera...
req = new XMLHttpRequest();
} else if(window.ActiveXObject) {
// Internet Explorer 5+
req = new ActiveXObject(Microsoft.XMLHTTP);
} else {
// There is an error creating the object,
// just as an old browser is being used.
alert('Problem creating the XMLHttpRequest object');
}
return req;
}
// Make the XMLHttpRequest object
var http = createRequestObject();
function sendRequest(action,arg) {
// Open PHP script for requests
http.open('get', 'eventaction.php?takeaction='+action+'uid='+arg);
http.onreadystatechange = handleResponse;
http.send(null);
}
function handleResponse() {
if(http.readyState == 4){
var response = http.responseText;
var update = new Array();
if(response.indexOf('|' != -1)) {
update = response.split('|');
document.getElementById(update[0]).innerHTML = update[1];
}
}
}
/script
/head
body
?php
$event['deleteevent']='a
href=javascript:sendRequest(delete,32423434234234234324)Delete this
event/a';
echo $event['deleteevent'];
?
/body
/html
this is the 'eventaction.php script yo test if the ajax script works
?
if($_GET['takeaction']==delete){
$uid=$_GET['uid'];
echo $uid;
exit;
}
?
Try firefox and take a look at the javascript console, it points you
to any javascript syntax errors.
Tijnema
---End Message---
---BeginMessage---
Richard Kurth wrote:
I can not figure out way this is not working can somebody help?
html
head
titleUntitled/title
script language=JavaScript
function createRequestObject() {
var req;
if(window.XMLHttpRequest){
// Firefox, Safari, Opera...
req = new XMLHttpRequest();
} else if(window.ActiveXObject) {
// Internet Explorer 5+
req = new ActiveXObject(Microsoft.XMLHTTP);
} else {
// There is an error creating the object,
// just as an old browser is being used.
alert('Problem creating the XMLHttpRequest object');
}
return req;
}
// Make the XMLHttpRequest object
var http = createRequestObject();
function sendRequest(action,arg) {
// Open PHP script for requests
http.open('get', 'eventaction.php?takeaction='+action+'uid='+arg);
http.onreadystatechange = handleResponse;
http.send(null);
}
function handleResponse() {
if(http.readyState == 4){
var response = http.responseText;
var update = new Array();
if(response.indexOf('|' != -1)) {
So, if it doesn't find a | (pipe) in the returned page, it won't do
anything!
update = response.split('|');
document.getElementById(update[0]).innerHTML = update[1];
}
}
}
/script
/head
body
?php
$event['deleteevent']='a
href=javascript:sendRequest(delete,32423434234234234324)Delete
Re: [PHP] Client does not support authentication protocol...
2007. 05. 28, hétfő keltezéssel 23.52-kor Tom ezt írta:
Hi, as always, I'm trying to connect to a MySQL database in the following
way:
mysql_connect('host','user','password');
In my local PC this Works perfectly, but in the server I receipt the
following error:
mysql_connect(): Client does not support authentication protocol requested
by server; consider upgrading MySQL client
Which can the cause of this error be?
Am I able to make something to solve it or does a problem belong exclusively
to the administrator of the server?
I've met this problem when I upgraded mysql-server from mysql 4.0 to
mysql 4.1
it was because mysql 4.1 and newer versions use a different password
encryption method. I think it can be solved by upgrading mysql-client
too. or you can issue the following mysql command on the server:
SET PASSWORD FOR [EMAIL PROTECTED] = OLD_PASSWORD('something');
which will solve it for that user without any upgrading
greets
Zoltán Németh
Thank you very much,
Tom.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: 1. script for login process is located on a SSL-enabled server, so usernames and passwords are encrypted. https:// is an envelope encryption, so POST data, which is a part of the packet data, not packet headers, is encrypted. As long as you POST or COOKIE data that needs encryption, you're fine. GET is not secure. What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted. 2. upon successful login, user is relocated to a non-SSL-enabled server which hosts the scripts that contain the authenticated-user-only features. If this is what you're doing (header() or a meta-refresh html tag). So, while usernames and passwords are protected by SSL, the PHPSESSID is not. In other words, anyone who captures that HTTP GET packet can get the session ID. Is that true? There are a few different attack vectors with SESSION data. Needless to say, never store or authenticate by a PHP SESSION id only; use cookies or encrypt a page with script and include() the content per page, and force users to login every page change. Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified. If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation. Another question is while that session ID is valid only before an unset() and a session_destroy(). So the attacker who has the session ID must fake the session before the real user logout. Is that true? Before the session is destroyed and the temp file where it is stored is deleted from the harddrive. Do not store sensitive information or use a SESSION id to authenticate a user. The session ID should be used for exactly what it says on the tin - identifying a session. PHP takes care of this for you by looking at the sessions it is maintaining for one matching the ID it's given. You can and should authenticate the continuation of a session based on the session ID (otherwise there's not much point having the session because the user will need to login for each page request), but you should not be storing the session ID anywhere because it's not a permanent value. To invalidate a session ID you just need to call session_destroy. There are people who do the following just to be sure that the data in a session is destroyed, but AFAIK it's not necessary... foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]); -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Web Application Design Literature
Steve, I have some experience developing web applications. My suggestion is to choose literature/code that uses PHP 4.x IF you plan on distributing the web application to multiple sites. But if instead you plan to have a single site web application, then use the literature/code for the latest and greatest PHP 5.x version. BTW you have a spartan website ;) Sincerely, Rob Steve wrote: Date: Mon, 28 May 2007 18:21:01 -0400 From: Steve Finkelstein [EMAIL PROTECTED] To: php-general@lists.php.net Subject: Web Application Design Literature Hello - I'm looking for recommendations on literature which will give me ideas on best practices for design and implementation of web applications, with if possible, PHP as its core reference language. Syntax has never been the challenge for me, like for most, it's always been the most practical and intelligent way to break up an application and focus on how to putting it all together for reusability and maintaining the application. Anyhow, suggestions are appreciated. Cheers! - sf -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt írta: Jared Farrish wrote: 1. script for login process is located on a SSL-enabled server, so usernames and passwords are encrypted. https:// is an envelope encryption, so POST data, which is a part of the packet data, not packet headers, is encrypted. As long as you POST or COOKIE data that needs encryption, you're fine. GET is not secure. What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted. 2. upon successful login, user is relocated to a non-SSL-enabled server which hosts the scripts that contain the authenticated-user-only features. If this is what you're doing (header() or a meta-refresh html tag). So, while usernames and passwords are protected by SSL, the PHPSESSID is not. In other words, anyone who captures that HTTP GET packet can get the session ID. Is that true? There are a few different attack vectors with SESSION data. Needless to say, never store or authenticate by a PHP SESSION id only; use cookies or encrypt a page with script and include() the content per page, and force users to login every page change. Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified. If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation. Another question is while that session ID is valid only before an unset() and a session_destroy(). So the attacker who has the session ID must fake the session before the real user logout. Is that true? Before the session is destroyed and the temp file where it is stored is deleted from the harddrive. Do not store sensitive information or use a SESSION id to authenticate a user. The session ID should be used for exactly what it says on the tin - identifying a session. PHP takes care of this for you by looking at the sessions it is maintaining for one matching the ID it's given. You can and should authenticate the continuation of a session based on the session ID (otherwise there's not much point having the session because the user will need to login for each page request), but you should not be storing the session ID anywhere because it's not a permanent value. To invalidate a session ID you just need to call session_destroy. There are people who do the following just to be sure that the data in a session is destroyed, but AFAIK it's not necessary... foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]); or just simply $_SESSION = array(); greets Zoltán Németh -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
Zoltán Németh wrote:
2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt írta:
Jared Farrish wrote:
1. script for login process is located on a SSL-enabled server, so
usernames and passwords are encrypted.
https:// is an envelope encryption, so POST data, which is a part of the
packet data, not packet headers, is encrypted. As long as you POST or
COOKIE
data that needs encryption, you're fine. GET is not secure.
What utter crud. An SSL connection encrypts the whole HTTP conversation,
including headers and even the URL you are requesting. The response is
also encrypted. It doesn't matter whether you're doing a POST or a GET
request, it's all encrypted.
2. upon successful login, user is relocated to a non-SSL-enabled server
which hosts the scripts that contain the authenticated-user-only
features.
If this is what you're doing (header() or a meta-refresh html tag).
So, while usernames and passwords are protected by SSL, the PHPSESSID is
not. In other words, anyone who captures that HTTP GET packet can get
the session ID. Is that true?
There are a few different attack vectors with SESSION data. Needless to
say,
never store or authenticate by a PHP SESSION id only; use cookies or
encrypt
a page with script and include() the content per page, and force users to
login every page change.
Cookies are no more secure than the session ID. The general conclusion
from many years of discussion in the web community is that the user
experience is diminished so much by not trusting a session ID that the
security improvements are not justified.
If you're really concerned then your best bet is to reduce the session
lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
store the user agent in the session and expire it if a request tries to
use an existing session with a different user agent. Unfortunately you
cannot rely on the IP address remaining the same throughout a session,
so don't build that into your session validation.
Another question is while that session ID is valid only before an
unset() and a session_destroy(). So the attacker who has the session ID
must fake the session before the real user logout. Is that true?
Before the session is destroyed and the temp file where it is stored is
deleted from the harddrive. Do not store sensitive information or use a
SESSION id to authenticate a user.
The session ID should be used for exactly what it says on the tin -
identifying a session. PHP takes care of this for you by looking at the
sessions it is maintaining for one matching the ID it's given. You can
and should authenticate the continuation of a session based on the
session ID (otherwise there's not much point having the session because
the user will need to login for each page request), but you should not
be storing the session ID anywhere because it's not a permanent value.
To invalidate a session ID you just need to call session_destroy. There
are people who do the following just to be sure that the data in a
session is destroyed, but AFAIK it's not necessary...
foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);
or just simply
$_SESSION = array();
I consider this is very bad practice, but I've just checked the manual
page for session_destory and it recommends the following to completely
destroy a session...
?php
// Initialize the session.
// If you are using session_name(something), don't forget it now!
session_start();
// Unset all of the session variables.
$_SESSION = array();
// If it's desired to kill the session, also delete the session cookie.
// Note: This will destroy the session, and not just the session data!
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}
// Finally, destroy the session.
session_destroy();
?
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] tinymce, php and mysql problem
Hi, I am using tinymce to save news articles with very basic html styling in a database. This works well upto a point but when I get over a certain number of characters and then the 'you have an error in your SQL syntax' error. I am saving in as a LONGBLOB so it should not be a data type mismatch. Any ideas? R. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] tinymce, php and mysql problem
2007. 05. 29, kedd keltezéssel 10.29-kor blueboy ezt írta: Hi, I am using tinymce to save news articles with very basic html styling in a database. This works well upto a point but when I get over a certain number of characters and then the 'you have an error in your SQL syntax' error. I am saving in as a LONGBLOB so it should not be a data type mismatch. Any ideas? I'm almost sure this is an escaping issue. Do you use mysql_real_escape_string() on the stuff you store in the db? greets Zoltán Németh R. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] tinymce, php and mysql problem
Zoltán Németh wrote: 2007. 05. 29, kedd keltezéssel 10.29-kor blueboy ezt írta: Hi, I am using tinymce to save news articles with very basic html styling in a database. This works well upto a point but when I get over a certain number of characters and then the 'you have an error in your SQL syntax' error. I am saving in as a LONGBLOB so it should not be a data type mismatch. Any ideas? I'm almost sure this is an escaping issue. Do you use mysql_real_escape_string() on the stuff you store in the db? greets Zoltán Németh R. If the mysql_real_escape_string doesn't solve it (which I think it most likely will), echo out the SQL query its sending and post it here so we can take a look. Darren -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] stack violation. after last line has been executed succesfully
Hello. I've confirmed this problem on my gentoo linux box and using Xampp on
windows..
= apache log =
[Mon May 28 20:38:47 2007] [notice] child pid 16577 exit signal Aborted (6)
*** glibc detected *** /usr/sbin/apache2: free(): invalid next size (fast):
0x082b4d28 ***
=== Backtrace: =
/lib/libc.so.6[0xb7b2b980]
/lib/libc.so.6(__libc_free+0x89)[0xb7b2cfe9]
/usr/lib/apache2/modules/libphp5.so(shutdown_memory_manager+0x48)[0xb77a0ef8]
/usr/lib/apache2/modules/libphp5.so(php_request_shutdown+0x478)[0xb7776ab8]
/usr/lib/apache2/modules/libphp5.so[0xb7839a18]
/usr/sbin/apache2(ap_invoke_handler+0x182)[0x806b992]
/usr/sbin/apache2(ap_process_request+0x15e)[0x806779e]
/usr/sbin/apache2(apr_vformatter+0xab0)[0x80611f8]
/usr/sbin/apache2(ap_process_connection+0x99)[0x80755b9]
/usr/sbin/apache2[0x8068bc1]
/usr/sbin/apache2[0x8068f56]
/usr/sbin/apache2(ap_mpm_run+0x67e)[0x806964e]
/usr/sbin/apache2(main+0x7df)[0x80701af]
/lib/libc.so.6(__libc_start_main+0xd8)[0xb7add838]
/usr/sbin/apache2(apr_bucket_mmap_make+0x69)[0x8060aa1]
=== Memory map:
08048000-080a r-xp 03:07 1310985/usr/sbin/apache2
080a-080a3000 rw-p 00058000 03:07 1310985/usr/sbin/apache2
080a3000-08349000 rw-p 080a3000 00:00 0 [heap]
b6d0-b6d21000 rw-p b6d0 00:00 0
= ===
My code snippets
1) lib_marc\trunk\pages\Page.php|12 col 14|
protected $pageContentObjects = array();
2) lib_marc\trunk\pages\Page.php|19 col 13|
$this-pageContentObjects[] = $pageContent;
[ 3) lib_marc\trunk\pages\Page.php|55 col 73|
$p = A::merge_ignore_null_array( U::collect('urlParameters',
$this-pageContentObjects) ); ]
4) lib_marc\trunk\pages\XHTMLPage.php|21 col 21|
foreach( $this-pageContentObjects as $pc){
1) this is the declaration
2) another object is added. when commenting this line out there is no problem
at all.
[3) doesn't matter]
4) This is foreach loop is causing the trouble even if the loop has an empty
body ( foreach (...) {} )
But I can run vardump on it and it shows the item having been added
by 2)
So how can this foreach loop make PHP causing a stack violation?
Any ideas?
You can get the full source code here:
wget http://mawercer.de/marcweber/da.zip
(I'll remove the link again in some days)
I'm using PDO and mysql. The database configuration options can be found in
config.php
Everything should be done automatically. (It does create a class location cache
to autoload them and it creates a file containing database metainformation to
execute type safe data queries.(MPDO.php) If you like it keep and use it and
drop me a mail telling so ;)
Main entry point is index.php of course.
You need to click on link Kunden or use
http://localhost/.../index.php?page=Kunden
to get this error.
I did use PHP 5.2.2 and mod_php (apache) I didn't try cgi.
Marc
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Streaming download to IE doesn't work
Daniel Kasak wrote: Hi all. Who knows WTF is wrong and how I can work around it? without getting into the holywar of download headers, here is one mans's take/solution: http://richardlynch.blogspot.com/2006_06_01_archive.html it should contain enough to help you out. PS. you might recognize the name from the list PPS. if you have STFA you would have have found this already, this download problem comes up regularly. -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: a question on session ID and security
On 5/29/07, Stut [EMAIL PROTECTED] wrote: What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted. The URL string is encrypted in HTTPS? Well, I was certainly under a different impression (same with headers). Since I can't say I know any better beyond a shadow of a doubt, I'll take your word for it. : ) Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified. So by storing sensitive information in a SESSION, you're safer? Only if the session doesn't get read... I don't know, I guess in the security sense, it should be seen as a part of the conversation as you put it, so if you can't trust SESSION, you probably shouldn't use it at all for secure applications. I still don't see the sense in storing sensitive information in a session, at least one that persists; if it is passed to a temp table in a database and destroyed across calls, I can see that as a better solution, as long as you have a strong database security configuration. If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation. Well, if you use COOKIES, you can pass a secondary hash key that can be used to validate the actual key against a footprint for a visitor (from $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like that's a pretty good way to check against a visitor. I just think it feels flimsy to validate a user on a SESSION key only. -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: If the only tool you have is a hammer, you tend to see every problem as a nail. $$ -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: If the only tool you have is a hammer, you tend to see every problem as a nail. $$
Re: [PHP] Re: Tipos about which CMS use
Hi, Thanks for the reply. I already use wordpress for my blog but not as a CMS. I could not find, for instance, the hability to create users with some sort of priviledge regarding reading/writing particular documents or areas. Can you send me more info about it? On 5/17/07, itoctopus [EMAIL PROTECTED] wrote: I've said it before and I'll say it again: Wordpress. Joomla/Mambo are also a good choice. -- itoctopus - http://www.itoctopus.com robert mena [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi there, I'd like to replace my 'intranet' site with a CMS system to speed up the edit process. Some of my requirements are : - written in PHP :) - mysql based - documented/'well structured' - to allow development of customizations - ability to define which pages or sections are public and which are private (and in this case which users can access) - use AJAX (not mandatory) but since some access to the page will come from dial-up to reduce the need to transfer entire html just to update a search or list contents.. thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Tipos about which CMS use
You could also try Drupal. Drupal 5 comes bundled with jQuery. Drupal is powerful and flexible and the community is large and supportive.
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: On 5/29/07, Stut [EMAIL PROTECTED] wrote: What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted. The URL string is encrypted in HTTPS? Well, I was certainly under a different impression (same with headers). Since I can't say I know any better beyond a shadow of a doubt, I'll take your word for it. : ) The only part of an SSL connection that's not encrypted is the handshaking that goes on to set it up in the first place. Everything after that, the GET/POST line, headers and the body as well as the entire response is encrypted. Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified. So by storing sensitive information in a SESSION, you're safer? Only if the session doesn't get read... I don't know, I guess in the security sense, it should be seen as a part of the conversation as you put it, so if you can't trust SESSION, you probably shouldn't use it at all for secure applications. I still don't see the sense in storing sensitive information in a session, at least one that persists; if it is passed to a temp table in a database and destroyed across calls, I can see that as a better solution, as long as you have a strong database security configuration. I never said it was safer to store sensitive information in a session - stop adding words! All I said was that the whole discussion of session security has been done to death and the conclusion is that you put the minimum possible on the client (the session ID) and store everything else on the server. If security is a big enough issue that you worry about data in the session being read then you need a dedicated server. If on the other hand you mean credit card information when you say sensitive data, there is no reason on earth why that should ever be *stored* anywhere on your server(s), even a temp table. As far as the relative security of cookies against sessions, they are basically as insecure as each other in most cases, but your cookies are at the mercy of the users setup which is something I'm just not willing to trust. The bottom line is that anything sent to or received from the user is insecure, and any security that can be added beyond SSL is easily worked around. If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation. Well, if you use COOKIES, you can pass a secondary hash key that can be used to validate the actual key against a footprint for a visitor (from $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like that's a pretty good way to check against a visitor. I just think it feels flimsy to validate a user on a SESSION key only. Indeed, you can validate a session by using certain information from the $_SERVER array, but bear in mind that none of it is necessarily persistant. I don't know of any examples, but I'm sure somewhere there is a crappy browser that changes its user agent for every request. However, of all the options I think the user agent is your best bet if you really feel you need to worry about it. In your comment above you seem to be suggesting passing that secondary hash key between requests via a cookie. Why not just store that in the session? Then it doesn't go outside your app. And as mentioned previously you have a lot more control over the session data than you do over cookie data. Here one final thought... if there was a reliable way to add security to sessions don't you think that one of the multitude of web development languages out there would have done it, including PHP? -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
On 5/29/07, Stut [EMAIL PROTECTED] wrote: The only part of an SSL connection that's not encrypted is the handshaking that goes on to set it up in the first place. Everything after that, the GET/POST line, headers and the body as well as the entire response is encrypted. One of these days I'm actually going to run some tests so I can see what is actually happening. I would sound completely ignorant speaking of packets as if I knew them that well, so I won't! I never said it was safer to store sensitive information in a session - stop adding words! All I said was that the whole discussion of session security has been done to death and the conclusion is that you put the minimum possible on the client (the session ID) and store everything else on the server. If security is a big enough issue that you worry about data in the session being read then you need a dedicated server. If on the other hand you mean credit card information when you say sensitive data, there is no reason on earth why that should ever be *stored* anywhere on your server(s), even a temp table. I find the best way to advice people on SESSIONS is not to trust them, and thus not store any kind of sensitive information within them (SSN, credit card, even phone numbers and whatnot). Since I don't happen to use sessions or cookies that often (for this reason), maybe my advice is a little biased. I store user data in cookies... One thing that makes this all completely irrevelent is that, for someone with physical access to authenticated browser session (such as an co-worker), no amount of security will prevent misuse of a session. As far as the relative security of cookies against sessions, they are basically as insecure as each other in most cases, but your cookies are at the mercy of the users setup which is something I'm just not willing to trust. True. I should have a fallback to use SESSION if cookies are not available, but if I'm doing that, why not go whole-hog? The bottom line is that anything sent to or received from the user is insecure, and any security that can be added beyond SSL is easily worked around. And SSL is rendered moot for users who gain browser access to an authenticated session. Security, I believe, is a matter of pushing vulnerabilities into a corner. You can't ever make any system completely secure, as such a system would be virtually useless. Well, if you use COOKIES, you can pass a secondary hash key that can be used to validate the actual key against a footprint for a visitor (from $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like that's a pretty good way to check against a visitor. I just think it feels flimsy to validate a user on a SESSION key only. Indeed, you can validate a session by using certain information from the $_SERVER array, but bear in mind that none of it is necessarily persistant. I don't know of any examples, but I'm sure somewhere there is a crappy browser that changes its user agent for every request. However, of all the options I think the user agent is your best bet if you really feel you need to worry about it. What happens if someone is behind a proxy? Never tested that, but if someone were to make a proxy sanitizer that purposefully skewed what it reports in the headers, that approach could be difficult to troubleshoot. In your comment above you seem to be suggesting passing that secondary hash key between requests via a cookie. Why not just store that in the session? Then it doesn't go outside your app. And as mentioned previously you have a lot more control over the session data than you do over cookie data. The whole point of using a shared hash is to provide notional benefit by providing a secondary key, that is stored on the browser, which is used to build the authenticated token, which is then matched to the server token. This is a type of security hash similar to the one you suggested above (using $_SERVER variables), only stored in a cookie. Different approach for different folks... : ) Here one final thought... if there was a reliable way to add security to sessions don't you think that one of the multitude of web development languages out there would have done it, including PHP? I certainly don't think you're implying I thought I had given some new, better way of doing sessions that nobody had given before? Curious statement. -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: If the only tool you have is a hammer, you tend to see every problem as a nail. $$
Re: [PHP] Upload a ppt file
At 11:07 PM +0200 5/28/07, Tijnema wrote: On 5/28/07, tedd [EMAIL PROTECTED] wrote: Hi Gang: I can upload a text file and an image file via a html form, but I am having problems uploading a PowerPoint file. Apparently, that's a different critter. Duh! Thanks for the hints -- it was stupid mistake on my part that. Sometimes you can get too carried away with trying to make things secure. It works fine now that I let it work. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: On 5/29/07, Stut [EMAIL PROTECTED] wrote: The only part of an SSL connection that's not encrypted is the handshaking that goes on to set it up in the first place. Everything after that, the GET/POST line, headers and the body as well as the entire response is encrypted. One of these days I'm actually going to run some tests so I can see what is actually happening. I would sound completely ignorant speaking of packets as if I knew them that well, so I won't! Sniff an SSL connection and you'll see it. Most of the traffic is gibberish! I never said it was safer to store sensitive information in a session - stop adding words! All I said was that the whole discussion of session security has been done to death and the conclusion is that you put the minimum possible on the client (the session ID) and store everything else on the server. If security is a big enough issue that you worry about data in the session being read then you need a dedicated server. If on the other hand you mean credit card information when you say sensitive data, there is no reason on earth why that should ever be *stored* anywhere on your server(s), even a temp table. I find the best way to advice people on SESSIONS is not to trust them, and thus not store any kind of sensitive information within them (SSN, credit card, even phone numbers and whatnot). Since I don't happen to use sessions or cookies that often (for this reason), maybe my advice is a little biased. I store user data in cookies... You do? What sort of data? Nothing sensitive I hope. One thing that makes this all completely irrevelent is that, for someone with physical access to authenticated browser session (such as an co-worker), no amount of security will prevent misuse of a session. The best you can hope to provide is end-to-end security and security on the server end. Anything beyond the connection at the client is out of your control and not worth worrying about. As far as the relative security of cookies against sessions, they are basically as insecure as each other in most cases, but your cookies are at the mercy of the users setup which is something I'm just not willing to trust. True. I should have a fallback to use SESSION if cookies are not available, but if I'm doing that, why not go whole-hog? Fallback to sessions? That makes no sense to me. Aside from the fact that you are storing application data on the client machine (which could be in a library for all you know), you are also transferring all that data for every page request. I really do think you should reconsider this approach. The bottom line is that anything sent to or received from the user is insecure, and any security that can be added beyond SSL is easily worked around. And SSL is rendered moot for users who gain browser access to an authenticated session. Security, I believe, is a matter of pushing vulnerabilities into a corner. You can't ever make any system completely secure, as such a system would be virtually useless. The only secure computer is one that's never switched on. Can't remember who said that, but it's completely true. However, the essence of a secure web application, for me, lies in not sending anything to the client that the client doesn't need to know about. Well, if you use COOKIES, you can pass a secondary hash key that can be used to validate the actual key against a footprint for a visitor (from $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like that's a pretty good way to check against a visitor. I just think it feels flimsy to validate a user on a SESSION key only. Indeed, you can validate a session by using certain information from the $_SERVER array, but bear in mind that none of it is necessarily persistant. I don't know of any examples, but I'm sure somewhere there is a crappy browser that changes its user agent for every request. However, of all the options I think the user agent is your best bet if you really feel you need to worry about it. What happens if someone is behind a proxy? Never tested that, but if someone were to make a proxy sanitizer that purposefully skewed what it reports in the headers, that approach could be difficult to troubleshoot. This is precisely my point. At some point you have to ask yourself whether it's worth worrying about? If you're dealing with high-value transactions then you probably need something more akin to a client-server solution than a web-based solution. That way you can control the client-side a lot better than you can in a web-based application. In your comment above you seem to be suggesting passing that secondary hash key between requests via a cookie. Why not just store that in the session? Then it doesn't go outside your app. And as mentioned previously you have a lot more control over the session data than you do over cookie data. The whole point of using a shared hash is to provide notional benefit by
Fwd: [PHP] Re: a question on session ID and security
On 5/29/07, Stut [EMAIL PROTECTED] wrote: Don't get me wrong, I don't want to discourage anyone from thinking about ways to improve it, but personally I consider this issue done to death. Well, I think the difference is that you send one key (a session identifier) and hash on user agent report, while I send an authentication key and a secondary hash key stored in cookies. I'm sending only nominally more information than you are, so I don't think there's THAT much difference between what we're saying here. As a lot of users would store session id's as cookies, and fall back to a query string id, like I said, I don't see much of a difference in our approaches, except you don't seem to think mine is acceptable since it's not a session id. If you supply the salt (instead of relying on it being provided, vis a vis, user agent report), and store that in a cookie on the client, and then that client can't reproduce an accurate, unchanged version of that cookie, what change in either the salt and/or the auth id would make this approach unacceptable (and not break the authentication)? I see major web firms use cookies all the time, so I'm not sure why there is a bias against cookies, besides a user that doesn't support cookies in the first place (which is a real concern, I admit). I remember a poster on a wall of a tech dept my friend worked for that had a faux-advert for a security dongle for a computer. Essentially, it was a rubber stopper that was put on a power cable that provided a 100% secure air gap. Whether it's been settled or not, I'm not nearly as played out on discussing it (especially if I'm not getting aspects correct) as I am about browser bickering, OS wars, and all the other dispassionate discourse currently enlightening the internet. At least with security, there's some known benefit to discussing it! -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: If the only tool you have is a hammer, you tend to see every problem as a nail. $$ -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: If the only tool you have is a hammer, you tend to see every problem as a nail. $$
Re: Fwd: [PHP] Re: a question on session ID and security
Jared Farrish wrote: On 5/29/07, Stut [EMAIL PROTECTED] wrote: Don't get me wrong, I don't want to discourage anyone from thinking about ways to improve it, but personally I consider this issue done to death. Well, I think the difference is that you send one key (a session identifier) and hash on user agent report, while I send an authentication key and a secondary hash key stored in cookies. I'm sending only nominally more information than you are, so I don't think there's THAT much difference between what we're saying here. As a lot of users would store session id's as cookies, and fall back to a query string id, like I said, I don't see much of a difference in our approaches, except you don't seem to think mine is acceptable since it's not a session id. That's not what I'm saying. My basic question is why send the secondary hash key to the client when it doesn't need it? Use the authentication key to identify the users data, then get the secondary hash key from that data. The browser never needs to see the hash, and from a purist security point of view it could potentially reveal more about your security methods than you need to. If you supply the salt (instead of relying on it being provided, vis a vis, user agent report), and store that in a cookie on the client, and then that client can't reproduce an accurate, unchanged version of that cookie, what change in either the salt and/or the auth id would make this approach unacceptable (and not break the authentication)? I see major web firms use But the point here is that both pieces of information required to authenticate that client are stored on the client. If someone can get one of them they can get the other, so it's no more secure than just accepting the one cookie without bothering to authenticate it in any way. cookies all the time, so I'm not sure why there is a bias against cookies, besides a user that doesn't support cookies in the first place (which is a real concern, I admit). I have nothing against cookies at all, but I think the line between cookies and session data is pretty clear. Cookies should be used to... a) remember a user between sessions (but not authenticate them) b) remember a session ID during a session c) remember user preferences for anonymous users, or where there is no such concept as users on the site Sessions should be used for everything else. If you're finding that you're storing huge amounts of data in cookies, switch to using sessions. If you find that you're storing so-called sensitive information in cookies, switch to sessions. I remember a poster on a wall of a tech dept my friend worked for that had a faux-advert for a security dongle for a computer. Essentially, it was a rubber stopper that was put on a power cable that provided a 100% secure air gap. Whether it's been settled or not, I'm not nearly as played out on discussing it (especially if I'm not getting aspects correct) as I am about browser bickering, OS wars, and all the other dispassionate discourse currently enlightening the internet. At least with security, there's some known benefit to discussing it! I'm more than happy to discuss it, but please tell me you got the point about whatever extra security is possible is likely to have been added by the majority of web application platforms, including PHP. I'm all for talking about it and seeing if there is a better way, but I also know that people far smarter than me have been talking about it for over 20 years, and what we have is what they've come up with. Ignoring the other possibilities like client certificates there's not really anything more you can do without introducing the possibility or even likelihood that the user experience will be shafted. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] ini_set() security question
I would be very interested in knowing which options, that are accessible with PHP_INI_ALL or PHP_INI_PERDIR, could be risky to allow on a shared hosting server. I would like to allow the users to ini_set(), while disabling the risky options with php_admin_flag/value! Stuff like 'memory_limit' and so on come to my mind! Does anybody have more infos on this? Regards, Samy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
That's not what I'm saying. My basic question is why send the secondary hash key to the client when it doesn't need it? Use the authentication key to identify the users data, then get the secondary hash key from that data. The browser never needs to see the hash, and from a purist security point of view it could potentially reveal more about your security methods than you need to. The idea is that the secondary hash key replaces the user agent sniff. But the point here is that both pieces of information required to authenticate that client are stored on the client. If someone can get one of them they can get the other, so it's no more secure than just accepting the one cookie without bothering to authenticate it in any way. The token isn't any more secure than tokenizing a user agent and salting it into a digest. The client still knows what their user agent string says, and this string can also be guessed (how random can they be?), but at least you can manipulate a secondary hash key per day/hour, week, whatever. I have nothing against cookies at all, but I think the line between cookies and session data is pretty clear. I would just ask where? (No, really.) If it was clear, then a link to a tutorial on PHP session security is helpful. Cookies should be used to... a) remember a user between sessions (but not authenticate them) b) remember a session ID during a session c) remember user preferences for anonymous users, or where there is no such concept as users on the site I agree 100% on everything except the logic on authentication. How would you finish the following: Sessions should be use to... a) ? b) ? c) ? Sessions should be used for everything else. If you're finding that you're storing huge amounts of data in cookies, switch to using sessions. If you find that you're storing so-called sensitive information in cookies, switch to sessions. I don't store anything in cookies that are meant to be useful on the server-side, save an auth string and a corresponding generated salt. This will probably change on my next big project, but for the moment, I'm not much of a fan of SESSIONS that persist. This is based on limited experience and anecdotal evidence, so opinions may very. I'm more than happy to discuss it, but please tell me you got the point about whatever extra security is possible is likely to have been added by the majority of web application platforms, including PHP. Of course. We're talking methodology (implementation of what is available), so I'm not sure why you feel the above is necessary. I'm all for talking about it and seeing if there is a better way, but I also know that people far smarter than me have been talking about it for over 20 years, and what we have is what they've come up with. Ignoring the other possibilities like client certificates there's not really anything more you can do without introducing the possibility or even likelihood that the user experience will be shafted. If it's an accepted methodology, please describe the entire methodology. If you think it's obvious, it should be easy, and a link is beneficial. I do think the stated best practice of SESSIONS, at this point, probably does need to be described to be further useful as a topic of discussion. I've been a little unclear in some things, so I get the feeling we've got the same point of view, with one slight deviation (I think it's slight...).
[PHP] exec dont work for svn
2007/5/28, Greg Donald [EMAIL PROTECTED]: On 5/28/07, Manolet Gmail [EMAIL PROTECTED] wrote: but this doesnt work: exec(svn update,$out); foreach($out as $line)echobr/$line\n; dont print anything... dont update the files Is it possible you need to provide some type of authentication? `svn update` may be asking for input your exec call isn't providing. well, i have error reporting (E ALL) and dont give me any error, also i try with svn update --non-interactive --username user --password pass and again... nothing appears. Also if the svn update ask for a password why php dont show it?, or why i dont receive a maximum ececution time of script error?. the script run instantly btw,.. -- Greg Donald http://destiney.com/ -- 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
Re: [PHP] Re: a question on session ID and security
On 5/29/07, Jared Farrish [EMAIL PROTECTED] wrote: I do think the stated best practice of SESSIONS, at this point, probably does need to be described to be further useful as a topic of discussion. I've been a little unclear in some things, so I get the feeling we've got the same point of view, with one slight deviation (I think it's slight...). Just thought I'd post this: Primer on PHP session security: http://www.php-mag.net/itr/online_artikel/psecom,id,513,nodeid,114.html -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: If the only tool you have is a hammer, you tend to see every problem as a nail. $$
[PHP] Re: Too many records to display in one web page
The way I handle it: Step 1- Add SELECT SQL_CALC_FOUND_ROWS to the front of your initial query and add the pagination limit to the end (LIMIT 200, 400 or whatever range you want to display.) Step 2- Do a 2nd query: SELECT FOUND_ROWS() immediately after. What does this do? It will return your record set within the limit range specified. However SQL_CALC_FOUND_ROWS also allows you to calculate how many total rows you would return if you had no limit. By running SELECT FOUND_ROWS() it will give you the total number of rows in the query. So for instance in the pseudo query above, mysql_num_rows would only return 200 on the query but SELECT FOUND_ROWS() might return 2000 if that's how many rows the query would return. Now you can use math to determine how many total pages you will have, what page you are on, etc so you can tweak the pagination to whatever suits your needs. Eduardo Vizcarra [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi All I am developing a web site that interacts with a MySQL database. When I run a query and display the records in a web page, this can become a problem because there might be too many records to be displayed in one single web page so I am trying to divide the total number of records and display them in multiple pages. Let's say, if the query returns 100 records then I would like to display the first 10 records and then put a navigation bar where I can go to the next 10 or return to the previous 10 records Is this done at a SQL or PHP level ? any experience on doing this ? Thanks a bunch Eduardo -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: That's not what I'm saying. My basic question is why send the secondary hash key to the client when it doesn't need it? Use the authentication key to identify the users data, then get the secondary hash key from that data. The browser never needs to see the hash, and from a purist security point of view it could potentially reveal more about your security methods than you need to. The idea is that the secondary hash key replaces the user agent sniff. But by doing that you're exposing how your app validates the authentication key, leaving it open to being transferred to another machine. But the point here is that both pieces of information required to authenticate that client are stored on the client. If someone can get one of them they can get the other, so it's no more secure than just accepting the one cookie without bothering to authenticate it in any way. The token isn't any more secure than tokenizing a user agent and salting it into a digest. The client still knows what their user agent string says, and this string can also be guessed (how random can they be?), but at least you can manipulate a secondary hash key per day/hour, week, whatever. It's actually less secure than using the user agent because someone looking at the cookies on the client gets no indication that you're using the user agent to verify that it's the same client making the request. I have nothing against cookies at all, but I think the line between cookies and session data is pretty clear. I would just ask where? (No, really.) If it was clear, then a link to a tutorial on PHP session security is helpful. I've asked the internals list why PHP doesn't natively validate the session ID by using the user agent or other variables because I actually don't know the reasoning behind it. I'll let you know what they say. Cookies should be used to... a) remember a user between sessions (but not authenticate them) b) remember a session ID during a session c) remember user preferences for anonymous users, or where there is no such concept as users on the site I agree 100% on everything except the logic on authentication. How would you finish the following: Sessions should be use to... a) ? b) ? c) ? a) Store data between requests b) There is no B That's the definition of a session. It's a server-side store of data related to a single user of a web application. Sessions should be used for everything else. If you're finding that you're storing huge amounts of data in cookies, switch to using sessions. If you find that you're storing so-called sensitive information in cookies, switch to sessions. I don't store anything in cookies that are meant to be useful on the server-side, save an auth string and a corresponding generated salt. This will probably change on my next big project, but for the moment, I'm not much of a fan of SESSIONS that persist. This is based on limited experience and anecdotal evidence, so opinions may very. By sessions that persist do you mean sessions that live on between visits by a user? If so then that's a totally different kettle of fish and IMHO should be avoided at all costs. I'm more than happy to discuss it, but please tell me you got the point about whatever extra security is possible is likely to have been added by the majority of web application platforms, including PHP. Of course. We're talking methodology (implementation of what is available), so I'm not sure why you feel the above is necessary. Look at the session facilities provided by any web development platform. They all work the same was as PHP sessions, that is to say storing a session ID in a cookie or passing it in URLs. I'm not aware of any system that uses extra validation, and the reason for that is that there is no guaranteed method. But you're right, the everybody-else-does-it-that-way argument is never very strong, but I think it's worth noting. As mentioned earlier, I have asked the internals list to give a reason why the session extension does no additional validation. I'm all for talking about it and seeing if there is a better way, but I also know that people far smarter than me have been talking about it for over 20 years, and what we have is what they've come up with. Ignoring the other possibilities like client certificates there's not really anything more you can do without introducing the possibility or even likelihood that the user experience will be shafted. If it's an accepted methodology, please describe the entire methodology. If you think it's obvious, it should be easy, and a link is beneficial. 20 years was an exaggeration given the age of the web, but the need to persist data related to any given user of a website between requests has been an issue for well over 10 years. The first solution was cookies. The problem with cookies is that they're very inefficient and insecure. Inefficient because they get transferred with every
[PHP] @imap_headerinfo-date
Dear Members! When I try to get email date through @imap_headerinfo the output like this Wed, 30 May 2007 01:14:03 +0900 Tue, 29 May 2007 22:31:43 +0500 But i want to change it e.g on current date it should be only time 01:14 PM and on previous day its should be (May 29) how i can do it plz help. Regards, Umar Draz -- View this message in context: http://www.nabble.com/%40imap_headerinfo-%3Edate-tf3835635.html#a10859574 Sent from the PHP - General mailing list archive at Nabble.com. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
But by doing that you're exposing how your app validates the authentication key, leaving it open to being transferred to another machine. True. Although I'm only exposing a part of the auth chain, not *how* that is constructed to produce the actual authentication token. It does not, however, tie the session to a specific browser instance on a remote machine; this is a problem. Of course, if the hash token uses the reported UA when created... :P It's actually less secure than using the user agent because someone looking at the cookies on the client gets no indication that you're using the user agent to verify that it's the same client making the request. But as you said, it's a reasonable thing to guess that it's being used as a salt or verifier, and may be spoofed using semi-random UA strings if you are testing for remote session hijacking weaknesses. If my salt changes according to a time/date/other, or is produced at random (somehow), even if it is transferred, it should still expire and be invalid by my own control. I've asked the internals list why PHP doesn't natively validate the session ID by using the user agent or other variables because I actually don't know the reasoning behind it. I'll let you know what they say. I would think it's because browsers are flaky and you can't really rely on them, and that means you can't build it into the system check. That's the definition of a session. It's a server-side store of data related to a single user of a web application. I think this is another reason why the internals don't support authentication of sessions. Is it up to a session to authenticate itself? Should it be? What if you wanted to override that behavior? By sessions that persist do you mean sessions that live on between visits by a user? If so then that's a totally different kettle of fish and IMHO should be avoided at all costs. I agree. :D Look at the session facilities provided by any web development platform. They all work the same was as PHP sessions, that is to say storing a session ID in a cookie or passing it in URLs. I'm not aware of any system that uses extra validation, and the reason for that is that there is no guaranteed method. Ah, so. You are right... But you're right, the everybody-else-does-it-that-way argument is never very strong, but I think it's worth noting. I don't mind this is standard practice, but EXPLAIN what you mean. What standard practice? This is an area that I want my knowledge to overlap others... Bruce Schneier, in all his glory, makes this point about roll-your-own security solutions: Bruce Scheier, http://www.schneier.com/essay-031-ft.txt The submission document for the algorithm I submitted with my colleagues at Counterpane was the length of a book. This [make hashing algorithms] is hard to do. But even normally rational people tend to be blinded by a bright shiny new algorithm. It seems so easy. The unfortunate truth is anybody can design an algorithm that he himself cannot break. It's actually profound. Anyone out there, from the best cryptographer to the random person on the street, can sit down with a pencil and paper, design an algorithm and say, I can't break it. And then here's the fallacy—because you can't break it, you make the following assumption: Therefore, it must be secure. So we end up with lots of proprietary algorithms. We have a lot of amateur cryptanalysts who will design the algorithms, do some work and then say, Look I can't break it, therefore it's secure. My feeling is that if the designers haven't proven themselves by breaking several published algorithms, why should I look at their designs? The odds of them being secure are pretty negligible. Indeed, the top five AES candidates—this is top five based on a formal poll of cryptographers—were actually designed by teams that have cryptanalysts on them. They seem to be the fastest, the most elegant, the best performing, the ones that seem to be the most secure. Still, nobody trusts them—give us a couple of years to stare at them. Eventually, we're going to have a new standard. There's no reason that I can think of ever to use a new and unanalyzed algorithm. There's never any benefit. There might be the personal pride of the designer. Other than that, you might as well use a known algorithm. So the moral there is never, ever trust a proprietary algorithm. I have to admit that some of this back-and-forth comes from my desire to get what I want out of your responses, which I know is probably a little frustrating. How do people who know little about PHP know what session best practices are, spelled out? I'm not a noob, but I've still learned a good deal from your responses that I didn't know before. What about the OP? 20 years was an exaggeration given the age of the web, but the need to persist data related to any given user of a website between requests has been an issue for well over 10 years. Sure, but referring to how long they've
RE: [PHP] exec dont work for svn
Hi, In many apps the messages comes as STDERR, so try: exec(svn update 21, $out); Best regards, Peter Lauri www.dwsasia.com - company web site www.lauri.se - personal web site www.carbonfree.org.uk - become Carbon Free -Original Message- From: Manolet Gmail [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 29, 2007 5:45 PM To: PHP List Subject: [PHP] exec dont work for svn 2007/5/28, Greg Donald [EMAIL PROTECTED]: On 5/28/07, Manolet Gmail [EMAIL PROTECTED] wrote: but this doesnt work: exec(svn update,$out); foreach($out as $line)echobr/$line\n; dont print anything... dont update the files Is it possible you need to provide some type of authentication? `svn update` may be asking for input your exec call isn't providing. well, i have error reporting (E ALL) and dont give me any error, also i try with svn update --non-interactive --username user --password pass and again... nothing appears. Also if the svn update ask for a password why php dont show it?, or why i dont receive a maximum ececution time of script error?. the script run instantly btw,.. -- Greg Donald http://destiney.com/ -- 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: I've asked the internals list why PHP doesn't natively validate the session ID by using the user agent or other variables because I actually don't know the reasoning behind it. I'll let you know what they say. I would think it's because browsers are flaky and you can't really rely on them, and that means you can't build it into the system check. I'm not sure how much closer to the horses mouth I can get... http://marc.info/?l=php-devm=118046750523448w=2 That's the definition of a session. It's a server-side store of data related to a single user of a web application. I think this is another reason why the internals don't support authentication of sessions. Is it up to a session to authenticate itself? Should it be? What if you wanted to override that behavior? Seeing as how the session functionality is provided through an extension, overriding it is simplicity itself. Plus there is already a way to implement a session handler in user space. I don't mind this is standard practice, but EXPLAIN what you mean. What standard practice? I'm sorry, I had assumed you knew how PHP sessions work. When a session is created it is assigned a unique ID. That ID is transported between the client and the server on each request. The server uses that ID to identify which session it is, get the data and make it available to the scripts. I have to admit that some of this back-and-forth comes from my desire to get what I want out of your responses, which I know is probably a little frustrating. How do people who know little about PHP know what session best practices are, spelled out? I'm not a noob, but I've still learned a good deal from your responses that I didn't know before. What about the OP? If there's anything you want me to go into in more detail please just ask. I certainly don't think I know it all, but I've been around this block more than a few times. On the other hand I'm always open to the possiblity that there's a better way(tm). In all reality, I actually agree with you about sessions in my heart-of-hearts (maybe a little more now after this thread), as they are the simplest to implement, and the checks performed on authentication are as robust as any involving cookies (which can become hopelessly bogged down in checks, digests, and rechecks), although I posit the SAME thing can be achieved with instances of cookies. However, simplicity should be the operative word, and the complexity of the approach I have described is more than a little troublesome. The same functionality can be achieved with cookies, just like the functionality of a calculator can be achieved with an abacus. I appreciate that you posted the historical information on sessions and cookies. Whether it's accurate to reality, I don't know, but it makes sense, not lemons, so for now, it's good enough for me! It was definitely abridged, but that's the jist of how sessions evolved. p.s. Maybe everyone wasn't around when that history occurred... Don't throw your youth at me, it's unlikely to help. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] exec dont work for svn
Hi, thanks petter, now im getting this error... svn: Can't check path '/root/.svn': Permission denied using this: $cmd = svn up; $cmd .= --username $user --password $pass --non-interactive --revision $rev; $cmd .= --no-auth-cache --config-dir ~/.svn/ 21; i try with --config-dir /tmp/ with $_SERVER['document_root'] but always return me the same error, any idea? 2007/5/29, Peter Lauri [EMAIL PROTECTED]: Hi, In many apps the messages comes as STDERR, so try: exec(svn update 21, $out); Best regards, Peter Lauri www.dwsasia.com - company web site www.lauri.se - personal web site www.carbonfree.org.uk - become Carbon Free -Original Message- From: Manolet Gmail [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 29, 2007 5:45 PM To: PHP List Subject: [PHP] exec dont work for svn 2007/5/28, Greg Donald [EMAIL PROTECTED]: On 5/28/07, Manolet Gmail [EMAIL PROTECTED] wrote: but this doesnt work: exec(svn update,$out); foreach($out as $line)echobr/$line\n; dont print anything... dont update the files Is it possible you need to provide some type of authentication? `svn update` may be asking for input your exec call isn't providing. well, i have error reporting (E ALL) and dont give me any error, also i try with svn update --non-interactive --username user --password pass and again... nothing appears. Also if the svn update ask for a password why php dont show it?, or why i dont receive a maximum ececution time of script error?. the script run instantly btw,.. -- Greg Donald http://destiney.com/ -- 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 -- 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
Re: [PHP] php and Ajax problem
Richard Kurth wrote:
if(response.indexOf('|' != -1)) {
Spot the misplaced bracket.
if($_GET['takeaction']==delete){
$uid=$_GET['uid'];
echo $uid;
This is wide open to XSS attacks, you need to be just as careful with
scripts intended to be accessed via javascript as you do with user
facing scripts. If uid is as it sounds, an integer, then
intval($_GET['uid']) will do nicely; otherwise at least use
htmlentities() to prevent XSS.
Arpad
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Streaming download to IE doesn't work
On Tue, 2007-05-29 at 13:52 +0200, Jochem Maas wrote: Daniel Kasak wrote: Hi all. Who knows WTF is wrong and how I can work around it? without getting into the holywar of download headers, here is one mans's take/solution: http://richardlynch.blogspot.com/2006_06_01_archive.html it should contain enough to help you out. PS. you might recognize the name from the list PPS. if you have STFA you would have have found this already, this download problem comes up regularly. Actually, that blog had absolutely nothing to do with my problem ( thanks for RTFP!). Not only that, but the recommendation that I construct URLs: http://address.com/script/thing=2/this=3/that=4/download.txt is patently ridiculous. Anyway, for people who will stumble across this bug in the future, check out: http://terra.di.fct.unl.pt/docs/php/function.session-cache-limiter.php.htm ... in particular, adding: header(Cache-control: private); header(Pragma: public); fixed things perfectly. Also note that things worked perfectly with normal http access from the start; this is required for streaming downloads to IE over *https* -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Too many records to display in one web page
Steve wrote: The way I handle it: Step 1- Add SELECT SQL_CALC_FOUND_ROWS to the front of your initial query and add the pagination limit to the end (LIMIT 200, 400 or whatever range you want to display.) Step 2- Do a 2nd query: SELECT FOUND_ROWS() immediately after. With a *HUGE* clause that this only works with mysql. There are other databases out there :P -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Client does not support authentication protocol...
Zoltán Németh wrote:
2007. 05. 28, hétfő keltezéssel 23.52-kor Tom ezt írta:
Hi, as always, I'm trying to connect to a MySQL database in the following
way:
mysql_connect('host','user','password');
In my local PC this Works perfectly, but in the server I receipt the
following error:
mysql_connect(): Client does not support authentication protocol requested
by server; consider upgrading MySQL client
Which can the cause of this error be?
Am I able to make something to solve it or does a problem belong exclusively
to the administrator of the server?
I've met this problem when I upgraded mysql-server from mysql 4.0 to
mysql 4.1
it was because mysql 4.1 and newer versions use a different password
encryption method. I think it can be solved by upgrading mysql-client
too. or you can issue the following mysql command on the server:
SET PASSWORD FOR [EMAIL PROTECTED] = OLD_PASSWORD('something');
Which is also listed on the same page on the mysql site :P
--
Postgresql php tutorials
http://www.designmagick.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] OOB problem, super stumped.
I am super stumped. This works fine separately but when I put everything
together it breaks. I has an authenticate class and a sql class. However I
always get the same error.
SQL class.
?php
class SQL {
public $host;
public $user;
public $pass;
public $conx;
public $db;
public $dbname;
public $query;
public $result;
public $fetchedArray;
public $nRows;
public function __construct($host,$user,$pass,$dbname = null){
$this-host=$host;
$this-user=$user;
$this-pass=$pass;
$this-conx=$this-connection($host,$user,$pass);
if (!is_null($dbname)){ $this-selectDb($dbname); }
}
final public function connection($host,$user,$pass){
$this-conx=mysql_connect($host,$user,$pass) or
die(mysql_error());
}
final public function selectDb($db){
$this-db=mysql_select_db($db);
}
final public function query($query){
$this-result=mysql_query($query, $this-conx);
echo mysql_error();
echo $query;
return $this-result;
}
final public function fetchArray($query){
$this-result=$this-query($query);
$this-fetchedArray=mysql_fetch_array($this-result,MYSQL_ASSOC);
return $this-fetchedArray;
}
final public function makeArray($query){
$this-curArray=mysql_fetch_array($query,MYSQL_ASSOC);
return $this-curArray;
}
final public function numRows($result)
{
$this-nRows=mysql_num_rows($result);
return $this-nRows;
}
public function __destruct(){
if (isset($this-connection)){
mysql_close($this-connection); }
}
}
?
Authenticate class
?php
class Authentication extends SQL {
public $errorMsg;
public function __construct(){echo Auth constructed;}
final public function verifyCreds ($user, $pass, $table)
{
$result = $this-query(SELECT * FROM $table where
$user='$pass');
if ($this-numRows($this-result) == 0)
{
$this-errorMsg = Incorrect Username/Password
Combo;
return false;
}
else
{
// debugging lines \/
echo login good!;
// debugging lines /\
return true;
}
}
public function __destruct(){}
}
?
Normal page.
?php
/
* common.php
*
* project: Renegades Revenge
* programmer: Brian Seymour
/
// autoload classes
function __autoload($class_name) {
require_once 'includes/classes/class_' . strtolower($class_name)
. '.php';
}
// initialize Renegades Revenge database
$database = new SQL($host,$user,$pass,aerocor_renegade);
// login
if (isset($_GET['login']))
{
$auth = new
Authentication($host,$user,$pass,aerocor_renegade);
if
($auth-verifyCreds($_POST['username'],$_POST['password'],players))
{
echo logged in good!;
}
}
?
The form is just 2 fields. Username and password. I get this error.
Warning: mysql_query(): supplied argument is not a valid MySQL-Link resource
in /home/aerocor/public_html/rr/includes/classes/class_sql.php on line 52
Warning: mysql_num_rows(): supplied argument is not a valid MySQL result
resource in /home/aerocor/public_html/rr/includes/classes/class_sql.php on
line 71
I put some simple query and display code in the constructor for the SQL
class and it outputted from the database with no problem, that's whats
weird.
Any help would be great, thanks.
Brian
Re: [PHP] OOB problem, super stumped.
On Tue, 2007-05-29 at 22:36 -0400, Brian Seymour wrote: I am super stumped. This works fine separately but when I put everything together it breaks. I has an authenticate class and a sql class. However I always get the same error. The following line: $this-conx=$this-connection($host,$user,$pass); Completely buggers things up. The connection() method doesn't return a value. So the next query has a null resource and so fails and generates the error you are seeing. You've already set the value of $this-conx in your connection() method so even if you did return the resource identifier it would be redundant. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] OOB problem, super stumped. (resolved)
Strangely enough the only thing that was wrong was: $this-result=mysql_query($query, $this-conx); I removed $this-conx so it looked like $this-result=mysql_query($query); And now everything works perfect. I also fixed the line you recommended I fix. I must have overlooked that =D. But anyhow, problem solved. Brian Seymour AeroCoreProductions http://www.aerocore.net/ -Original Message- From: Robert Cummings [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 29, 2007 10:51 PM To: Brian Seymour Cc: 'php php' Subject: Re: [PHP] OOB problem, super stumped. On Tue, 2007-05-29 at 22:36 -0400, Brian Seymour wrote: I am super stumped. This works fine separately but when I put everything together it breaks. I has an authenticate class and a sql class. However I always get the same error. The following line: $this-conx=$this-connection($host,$user,$pass); Completely buggers things up. The connection() method doesn't return a value. So the next query has a null resource and so fails and generates the error you are seeing. You've already set the value of $this-conx in your connection() method so even if you did return the resource identifier it would be redundant. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- 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
RE: [PHP] OOB problem, super stumped. (resolved)
On Tue, 2007-05-29 at 23:07 -0400, Brian Seymour wrote: Strangely enough the only thing that was wrong was: $this-result=mysql_query($query, $this-conx); I removed $this-conx so it looked like $this-result=mysql_query($query); NO NO NO... don't do that. If you remove the link identifier then mysql_query() defaults to the last connection opened. In which case if you make more than one DB connection, you'll have connection soup. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOB problem, super stumped.
Brian Seymour wrote:
I am super stumped. This works fine separately but when I put everything
together it breaks. I has an authenticate class and a sql class. However I
always get the same error.
SQL class.
?php
class SQL {
public $host;
public $user;
public $pass;
public $conx;
public $db;
public $dbname;
public $query;
public $result;
public $fetchedArray;
public $nRows;
public function __construct($host,$user,$pass,$dbname = null){
$this-host=$host;
$this-user=$user;
$this-pass=$pass;
$this-conx=$this-connection($host,$user,$pass);
if (!is_null($dbname)){ $this-selectDb($dbname); }
}
final public function connection($host,$user,$pass){
$this-conx=mysql_connect($host,$user,$pass) or
die(mysql_error());
}
final public function selectDb($db){
$this-db=mysql_select_db($db);
}
final public function query($query){
$this-result=mysql_query($query, $this-conx);
echo mysql_error();
echo $query;
return $this-result;
}
final public function fetchArray($query){
$this-result=$this-query($query);
$this-fetchedArray=mysql_fetch_array($this-result,MYSQL_ASSOC);
return $this-fetchedArray;
}
final public function makeArray($query){
$this-curArray=mysql_fetch_array($query,MYSQL_ASSOC);
return $this-curArray;
}
final public function numRows($result)
{
$this-nRows=mysql_num_rows($result);
return $this-nRows;
}
public function __destruct(){
if (isset($this-connection)){
mysql_close($this-connection); }
}
}
?
Authenticate class
?php
class Authentication extends SQL {
public $errorMsg;
public function __construct(){echo Auth constructed;}
You didn't call the __construct() method of your parent.
The above code, should be like this
public function __construct($host,$user,$pass,$dbname = null) {
parent::__construct($host,$user,$pass,$dbname);
echo Auth constructed;
}
You were forgetting to call to the parent and have it initialize the DB
connection.
In the second part, the $auth-verifyCreds() call, it didn't create a
valid db connection to pass as the second arg to the mysql_query() call.
And by not passing the $this-conx as the second arg, you are telling it
to use the most recently opened mysql connection.
Hope this clears up why it was failing on the latter mysql_query() calls.
final public function verifyCreds ($user, $pass, $table)
{
$result = $this-query(SELECT * FROM $table where
$user='$pass');
if ($this-numRows($this-result) == 0)
{
$this-errorMsg = Incorrect Username/Password
Combo;
return false;
}
else
{
// debugging lines \/
echo login good!;
// debugging lines /\
return true;
}
}
public function __destruct(){}
}
?
Normal page.
?php
/
* common.php
*
* project: Renegades Revenge
* programmer: Brian Seymour
/
// autoload classes
function __autoload($class_name) {
require_once 'includes/classes/class_' . strtolower($class_name)
. '.php';
}
// initialize Renegades Revenge database
$database = new SQL($host,$user,$pass,aerocor_renegade);
// login
if (isset($_GET['login']))
{
$auth = new
Authentication($host,$user,$pass,aerocor_renegade);
if
($auth-verifyCreds($_POST['username'],$_POST['password'],players))
{
echo logged in good!;
}
}
?
The form is just 2 fields. Username and password. I get this error.
Warning: mysql_query(): supplied argument is not a valid MySQL-Link resource
in
