php-general Digest 16 Aug 2011 08:14:20 -0000 Issue 7445
php-general Digest 16 Aug 2011 08:14:20 - Issue 7445 Topics (messages 314529 through 314538): Re: Keeping session info in $_SESSION or in database? 314529 by: Stuart Dallas 314530 by: Philip Thompson 314531 by: LAMP 314532 by: Stuart Dallas 314533 by: Philip Thompson 314534 by: Ashley Sheridan 314535 by: Andrew Ballard 314537 by: Richard Quadling Newbie question. What is the best structure of a php-app? 314536 by: Andreas (Kinda sorta) PHP related: recovering lost passwords 314538 by: James Colannino 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--- On 15 Aug 2011, at 19:43, LAMP wrote: This is THE question that bothers me for a while... I always was keeping session info, like user ID, organization ID, selected book ID... within $_SESSION array. Main reason is to access and maintain it faster than keeping them inside session table. And, also, one less mysql connection. Though, in last project the $_SESSION grow up to around 30, even 50 elements of the array. And several people mentioned it's better to keep so big session data in mysql than in $_SESSION. My question is pros and cons $_SESSION vs. mysql session. And, if the amount of data is only reason, when is better to keep all data in $_SESSION and when to store them in mysql? 1) 30-50 array elements says nothing about the size of the data. That's like saying you have 30-50 piece of paper and assuming that means they contain a lot of text. If each array element is simply a number then 30-50 is not even close to being big. 2) Size of data is never good reason why you'd switch your session storage from files to a database. The data still needs to be read and unserialised at the start of a request, and serialised and written back at the end. In fact, with larger amounts of data you may find file-based storage to be faster. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/---End Message--- ---BeginMessage--- Crap! I wish this list would have a reply-to list automatically -- Forwarded message -- From: Philip Thompson philthath...@gmail.com Date: Mon, Aug 15, 2011 at 2:11 PM Subject: Re: [PHP] Keeping session info in $_SESSION or in database? To: LAMP l...@afan.net On Mon, Aug 15, 2011 at 1:43 PM, LAMP l...@afan.net wrote: Hi all, This is THE question that bothers me for a while... I always was keeping session info, like user ID, organization ID, selected book ID... within $_SESSION array. Main reason is to access and maintain it faster than keeping them inside session table. And, also, one less mysql connection. Though, in last project the $_SESSION grow up to around 30, even 50 elements of the array. And several people mentioned it's better to keep so big session data in mysql than in $_SESSION. My question is pros and cons $_SESSION vs. mysql session. And, if the amount of data is only reason, when is better to keep all data in $_SESSION and when to store them in mysql? Thanks for any help, LAMP Hi all. Long time no see. I personally think 30-50 elements in an array is not a lot of data (unless you're storing hundreds of megs of data per element). You really have to weigh the pros and cons of using file-based session storage versus database session storage. With a quick google search, this article by Chris Shiftlett came up: http://shiflett.org/articles/storing-sessions-in-a-database. Specially look at the background section. It goes over a couple reasons to use a database. While this list is not exhaustive by any means, it should get you thinking. If the biggest reason for wanting to use a database over the file system is because of the space, then you may want to reconsider In file-based session storage, the session data is saved in a particular location (as specified in php.ini). So, if you have 10MB of data, this will be will stored in a file slightly larger than 10MB because I believe the data is serialized in some form. This file is accessed upon page load and is written to for the next page request. File I/O is generally pretty fast... generally much faster than database I/O. In the database storage, you must run queries to pull the data necessary. This requires a connection plus the time to query plus the time to organize the data. If you have 10MB of data, then you still have to pull all of that from the database, so I don't believe you're getting any speed advantage. If you're application is running on multiple servers, then you'd want to consider the database storage. IMO, only use the database (for session storage) if it solves a problem that can be easily fixed otherwise by using
[PHP] (Kinda sorta) PHP related: recovering lost passwords
Hi everyone, I don't post all that often, so I hope my (mildly) off-topic question won't be too unwelcome... Keep in mind that I'm still pretty new when it comes to security, so what I propose may or may not sound incredibly dumb (you have been warned! :-P) I'm working on a project in PHP, a toy framework, and would really like to be able to send someone their password should they ever forget it. The only problem is that it's best not to store the actual password in the database, or at least to store it unencrypted. Security-wise, how would the following scenario work out for password retrieval: You ask the user to setup a security question when they create their account. You use the string value of the answer to the question as a cryptographic key, and encrypt the password with it. You also generate a random string of characters, and encrypt it with the same key. You store the encrypted password, along with both the encrypted and unencrypted versions of the randomly generated string, in the database. When the user goes to retrieve their password, they enter their security question. The randomly generated string is then decrypted using the answer as the key. If it matches the unencrypted version stored in the database, you know you have the correct answer, and use it to decrypt the user's password and send it to the email the user has setup for their account. James -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] (Kinda sorta) PHP related: recovering lost passwords
James Colannino wrote: If it matches the unencrypted version stored in the database, you know you have the correct answer, and use it to decrypt the user's password and send it to the email the user has setup for their account. All the good sites simply don't have that capability ... Much safer rather than 'recovering' a password is to identify the user, and send them a temporary password which they have to change when they log in. This way nobody is allowed access existing passwords ;) -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Newbie question. What is the best structure of a php-app?
Hi, Surely there's a wiki/doc somewhere :) But for the start: 1) plan what exactly you want to accomplish ( functionality ) 2) complexity - if simple, just throw it in one php ( like index.php ) - if more complex, you can separate the pages and/or use classes 3) based on 2), plan the structure ( I'm using mostly one entry point - index.php - with classes, templates, files included, since I like things separated ) Some thing you should not forget: - whole webapp thing is event based ( client will do something - press a link - and the server will react ) - the connection is not maintained all the time - PHP is server side (harder to debug), you cannot do anything on client side ( just push what to display ) ( JS is client side ) - you can start the session whenever you want ( it's nearly the first line of my app ), but you should control the access with variables, like if ( $_SESSION['uid'] ) or if ( $_SESSION['loggedin'] ) - most webservers interprets things between ?php ? even if the file name ends with .htm or .html - for JS and connection related things FireBug for FireFox is a good idea ( you can track, what's submitted, etc ) What I'm liking: - one entry point ( index.php ) - sub-pages, are separate php/template pairs BUT are included from index.php ( after access verification, etc ) - nearly all the functions are put in separate classes ( like user.class.php for user related things - login,logout, etc ) - using a template engine is not a very bad idea ( like Smarty ), you can separate the real code from html, which make debugging easier - at least for me :) BTW, take a look on some free stuff. You can always learn from others. There are some good ideas in open CMS systems, like Joomla. Cheers, Tom -Original Message- From: Andreas [mailto:maps...@gmx.net] Sent: Tuesday, August 16, 2011 12:39 AM To: php-general@lists.php.net Subject: [PHP] Newbie question. What is the best structure of a php-app? Hi, I'm fairly new to PHP but not to programming as such. Currently I sat up XAMPP with xdebug, Netbeans and Eclipse to get a feeling. I can write and run php-files but I am wondering how I should construct a more complex application that runs over several pages between a login and a logout. How would I structure such an application so that it is possible to run it in the debugger from the beginning? E.g. as a simple example I may build an index.html that has a menue with links to 3 php-files. 1) login.php 2) enter_data.php 3) list_data.php as html-links within an ul-list. The user should at first click on login where user/password gets entered an a session starts. Then the application comes back to index.html. Now he might click 2) ... Is it possible to run the whole application from the start on? index.html is no php so xdebug won't process it and therefore the IDEs may start index.html but can't show the stage where the page is just waiting e.g. for a click on login and later branch for the other options. Even if I write an index.php that shows the menue eventually the script just dumps the html that'll wait for the following clicks. Those following steps are far more likely in need to be debugged. Is it neccessary to debug those subpages separately even though they need prior steps like login.php that store some infos in a session or cookie that later scripts need to rely on? Can I somehow watch what is going on from the index.html on? Until now I just found documentation that explains the php language. Thats good too but I'd need to get an idea about the web-app-thinking that consist of just pages where the designer has to hope that the user stays within the applicationflow instead of clicking unexpectedly on the back-button or just jumping off to some other site if he likes to. In contrast to this desktop-apps seem to be less demanding because I know where a user can navigate from a certain stage within the app and I could step from program start to stop with the debugger if I feel the need to. Is there a tutorial that explains how to build consistent web-apps beyond the details of php language? regards... -- 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] (Kinda sorta) PHP related: recovering lost passwords
On 16 August 2011 09:14, James Colannino ja...@colannino.org wrote: Hi everyone, I don't post all that often, so I hope my (mildly) off-topic question won't be too unwelcome... Keep in mind that I'm still pretty new when it comes to security, so what I propose may or may not sound incredibly dumb (you have been warned! :-P) I'm working on a project in PHP, a toy framework, and would really like to be able to send someone their password should they ever forget it. The only problem is that it's best not to store the actual password in the database, or at least to store it unencrypted. Security-wise, how would the following scenario work out for password retrieval: You ask the user to setup a security question when they create their account. You use the string value of the answer to the question as a cryptographic key, and encrypt the password with it. You also generate a random string of characters, and encrypt it with the same key. You store the encrypted password, along with both the encrypted and unencrypted versions of the randomly generated string, in the database. When the user goes to retrieve their password, they enter their security question. The randomly generated string is then decrypted using the answer as the key. If it matches the unencrypted version stored in the database, you know you have the correct answer, and use it to decrypt the user's password and send it to the email the user has setup for their account. James -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Take a look at https://code.google.com/p/loginsystem-rd/ Whilst it is just a login system, the techniques here could be adapted and probably learned from (if you are new to security). -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Newbie question. What is the best structure of a php-app?
On 16 August 2011 09:53, Dajka Tamás vi...@vipernet.hu wrote: Hi, Surely there's a wiki/doc somewhere :) But for the start: 1) plan what exactly you want to accomplish ( functionality ) 2) complexity - if simple, just throw it in one php ( like index.php ) - if more complex, you can separate the pages and/or use classes 3) based on 2), plan the structure ( I'm using mostly one entry point - index.php - with classes, templates, files included, since I like things separated ) Some thing you should not forget: - whole webapp thing is event based ( client will do something - press a link - and the server will react ) - the connection is not maintained all the time - PHP is server side (harder to debug), you cannot do anything on client side ( just push what to display ) ( JS is client side ) - you can start the session whenever you want ( it's nearly the first line of my app ), but you should control the access with variables, like if ( $_SESSION['uid'] ) or if ( $_SESSION['loggedin'] ) - most webservers interprets things between ?php ? even if the file name ends with .htm or .html - for JS and connection related things FireBug for FireFox is a good idea ( you can track, what's submitted, etc ) What I'm liking: - one entry point ( index.php ) - sub-pages, are separate php/template pairs BUT are included from index.php ( after access verification, etc ) - nearly all the functions are put in separate classes ( like user.class.php for user related things - login,logout, etc ) - using a template engine is not a very bad idea ( like Smarty ), you can separate the real code from html, which make debugging easier - at least for me :) BTW, take a look on some free stuff. You can always learn from others. There are some good ideas in open CMS systems, like Joomla. Cheers, Tom -Original Message- From: Andreas [mailto:maps...@gmx.net] Sent: Tuesday, August 16, 2011 12:39 AM To: php-general@lists.php.net Subject: [PHP] Newbie question. What is the best structure of a php-app? Hi, I'm fairly new to PHP but not to programming as such. Currently I sat up XAMPP with xdebug, Netbeans and Eclipse to get a feeling. I can write and run php-files but I am wondering how I should construct a more complex application that runs over several pages between a login and a logout. How would I structure such an application so that it is possible to run it in the debugger from the beginning? E.g. as a simple example I may build an index.html that has a menue with links to 3 php-files. 1) login.php 2) enter_data.php 3) list_data.php as html-links within an ul-list. The user should at first click on login where user/password gets entered an a session starts. Then the application comes back to index.html. Now he might click 2) ... Is it possible to run the whole application from the start on? index.html is no php so xdebug won't process it and therefore the IDEs may start index.html but can't show the stage where the page is just waiting e.g. for a click on login and later branch for the other options. Even if I write an index.php that shows the menue eventually the script just dumps the html that'll wait for the following clicks. Those following steps are far more likely in need to be debugged. Is it neccessary to debug those subpages separately even though they need prior steps like login.php that store some infos in a session or cookie that later scripts need to rely on? Can I somehow watch what is going on from the index.html on? Until now I just found documentation that explains the php language. Thats good too but I'd need to get an idea about the web-app-thinking that consist of just pages where the designer has to hope that the user stays within the applicationflow instead of clicking unexpectedly on the back-button or just jumping off to some other site if he likes to. In contrast to this desktop-apps seem to be less demanding because I know where a user can navigate from a certain stage within the app and I could step from program start to stop with the debugger if I feel the need to. Is there a tutorial that explains how to build consistent web-apps beyond the details of php language? regards... I like the Zend Framework layout where the class names and file names are created according to a standard (http://groups.google.com/group/php-standards/web/psr-0-final-proposal?pli=1) And by putting the codebase outside of docroot (include_path is your friend here), you allow the framework to be used on multiple sites on the same server. For me, the only things I have in my docroot are statics (css, js, images, html) and index.php (though occasional one-shot utils will exist there). When I develop, I have 3 versions of the site (live, test and dev). www.site.com, test.site.com and dev.site.com I have separate SQL Server instances (I'm on Windows and mainly develop for MS SQL Server -
Re: [PHP] (Kinda sorta) PHP related: recovering lost passwords
On 2011-08-16, at 5:08 AM, Richard Quadling rquadl...@gmail.com wrote: On 16 August 2011 09:14, James Colannino ja...@colannino.org wrote: Hi everyone, I don't post all that often, so I hope my (mildly) off-topic question won't be too unwelcome... Keep in mind that I'm still pretty new when it comes to security, so what I propose may or may not sound incredibly dumb (you have been warned! :-P) I'm working on a project in PHP, a toy framework, and would really like to be able to send someone their password should they ever forget it. The only problem is that it's best not to store the actual password in the database, or at least to store it unencrypted. Security-wise, how would the following scenario work out for password retrieval: You ask the user to setup a security question when they create their account. You use the string value of the answer to the question as a cryptographic key, and encrypt the password with it. You also generate a random string of characters, and encrypt it with the same key. You store the encrypted password, along with both the encrypted and unencrypted versions of the randomly generated string, in the database. When the user goes to retrieve their password, they enter their security question. The randomly generated string is then decrypted using the answer as the key. If it matches the unencrypted version stored in the database, you know you have the correct answer, and use it to decrypt the user's password and send it to the email the user has setup for their account. James -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Take a look at https://code.google.com/p/loginsystem-rd/ Whilst it is just a login system, the techniques here could be adapted and probably learned from (if you are new to security). -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Never never send emails with passwords. I have a number of clients who are requesting that the user answer a security question and then it emails a link with a defined lifespan which will allow them to change the password. If they don't click the link in time, it expires and the process starts all over again. Bastien -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Why count() returns no error when string is given ?
For example when I do:
strlen(array(1,2,3));
php shows: Warning: strlen() expects parameter 1 to be string, array
given in...
but when I do:
count('string');
It simply returns 1 like nothing happened. I would expect such
behavior if I write:
count((array)'string')
but otherwise such behavior is very misleading and inconsistent.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Why count() returns no error when string is given ?
Le 16/08/2011 16:29, rs...@live.com a écrit :
For example when I do:
strlen(array(1,2,3));
php shows: Warning: strlen() expects parameter 1 to be string, array
given in...
but when I do:
count('string');
It simply returns 1 like nothing happened. I would expect such
behavior if I write:
count((array)'string')
but otherwise such behavior is very misleading and inconsistent.
manual : function.count.php
Returns the number of elements in/var/. If/var/is not an array or an
object with implementedCountable
http://www.php.net/manual/en/class.countable.phpinterface,/1/will be
returned. There is one exception, if/var/is*NULL*,/0/will be returned.
Re: [PHP] Why count() returns no error when string is given ?
Le 16/08/2011 16:32, Florian Lemaitre a écrit :
Le 16/08/2011 16:29, rs...@live.com a écrit :
For example when I do:
strlen(array(1,2,3));
php shows: Warning: strlen() expects parameter 1 to be string, array
given in...
but when I do:
count('string');
It simply returns 1 like nothing happened. I would expect such
behavior if I write:
count((array)'string')
but otherwise such behavior is very misleading and inconsistent.
manual : function.count.php
Returns the number of elements in/var/. If/var/is not an array or an
object with implementedCountable
http://www.php.net/manual/en/class.countable.phpinterface,/1/will be
returned. There is one exception, if/var/is*NULL*,/0/will be returned.
Oups...
Returns the number of elements in var. If var is not an array or an
object with implemented Countable interface, 1 will be returned. There
is one exception, if var is NULL, 0 will be returned.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Why count() returns no error when string is given ?
Hello Florian, Tuesday, August 16, 2011, 4:32:39 PM, you wrote: manual : function.count.php Returns the number of elements in/var/. If/var/is not an array or an object with implementedCountable http://www.php.net/manual/en/class.countable.phpinterface,/1/will be returned. There is one exception, if/var/is*NULL*,/0/will be returned. Yes I know, but I wonder what is the master reason behind this line of doing things ? The fact that something is documented shoudn't make it automatically right. Are there scripts where people are putting strings into count by purpose, not by an accident ? Is this behavior having some grand purpose behind id, or is it just a historical accident for early days of php ? -- Best regards, rsk82mailto:rs...@live.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Why count() returns no error when string is given ?
Le 16/08/2011 16:50, rs...@live.com a écrit : Hello Florian, Tuesday, August 16, 2011, 4:32:39 PM, you wrote: manual : function.count.php Returns the number of elements in/var/. If/var/is not an array or an object with implementedCountable http://www.php.net/manual/en/class.countable.phpinterface,/1/will be returned. There is one exception, if/var/is*NULL*,/0/will be returned. Yes I know, but I wonder what is the master reason behind this line of doing things ? The fact that something is documented shoudn't make it automatically right. Are there scripts where people are putting strings into count by purpose, not by an accident ? Is this behavior having some grand purpose behind id, or is it just a historical accident for early days of php ? this question has already been discussed 8 days ago in this mailing list. You can see the archive here : http://www.mail-archive.com/php-general@lists.php.net/msg267800.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] (Kinda sorta) PHP related: recovering lost passwords
On 08/16/11 01:30, Lester Caine wrote: All the good sites simply don't have that capability ... Much safer rather than 'recovering' a password is to identify the user, and send them a temporary password which they have to change when they log in. This way nobody is allowed access existing passwords ;) Good point. I think I'll go that route instead. James -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Secure vs httpOnly cookie flag: is one better?
Thank you in advance for your input on my question here . I am currently running PHP 5.1.6 and would prefer to set both the secure and httpOnly flags for a session cookie, however, httpOnly is not added until PHP 5.2. I have found an elegant way to set it ( courtesy of : http://www.youtube.com/watch?v=UW0UhYfs1es ) but I am unable to set both the secure and the httpOnly flags. I realize the post is quite old, but doh!, so is my version of PHP J My guess is that if forced to choose, I should opt for secure but would prefer to do so with any opinions you may offer in mind. Thanks!! Jen
Re: [PHP] (Kinda sorta) PHP related: recovering lost passwords
On 08/16/11 02:08, Richard Quadling wrote: Take a look at https://code.google.com/p/loginsystem-rd/ Whilst it is just a login system, the techniques here could be adapted and probably learned from (if you are new to security). Ah, that looks interesting. Thanks for the link! James -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure vs httpOnly cookie flag: is one better?
On Tue, Aug 16, 2011 at 1:01 PM, Jen Rasmussen j...@cetaceasound.com wrote:
Thank you in advance for your input on my question here .
I am currently running PHP 5.1.6 and would prefer to set both the secure and
httpOnly flags for a session cookie,
however, httpOnly is not added until PHP 5.2. I have found an elegant way to
set it ( courtesy of : http://www.youtube.com/watch?v=UW0UhYfs1es ) but I am
unable to set both the secure and the httpOnly flags. I realize the post is
quite old, but doh!, so is my version of PHP J
My guess is that if forced to choose, I should opt for secure but would
prefer to do so with any opinions you may offer in mind.
I don't see the relevance of the address you cited above, but if you
are referring to the workaround that I showed you last week --
http://marc.info/?l=php-generalm=131281548332245w=2
-- you can easily extend the technique to set both flags.
header('Set-Cookie: cookie_name=value; secure; HttpOnly');
Andrew
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Secure vs httpOnly cookie flag: is one better?
Andrew,
Wow, copied and pasted in the wrong link ...no wonder it made no sense -
WHOOPS!!
The correct link is:
http://blog.mattmecham.com/2006/09/12/http-only-cookies-without-php-52/comment-page-1/#comment-14609
Below are the methods I WAS working with (similar to your recommendation last
week - thank you) and expanded with the blog post above recommendations.
@setcookie( $name, $value, $expires, $path, $domain . '; HttpOnly' ); sets http
flag but not secure (not included)
@setcookie( $name, $value, $expires, $path, $domain, TRUE ); // sets secure but
not http (not included)
@setcookie( $name, $value, $expires, $path, $domain, TRUE . '; HttpOnly' ); //
sets secure but not http (included)
What I've landed on in case this helps anyone else is the following:
@setcookie( $name, $value, $expires, $path, $domain . 'secure; HttpOnly' ); //
this sets both http flag and secure
What made it work was using the word secure rather than a Boolean value and
putting it within the quotes along with HttpOnly.
Thanks!
Jen
-Original Message-
From: Andrew Ballard [mailto:aball...@gmail.com]
Sent: Tuesday, August 16, 2011 1:06 PM
To: j...@cetaceasound.com
Cc: php-general@lists.php.net
Subject: Re: [PHP] Secure vs httpOnly cookie flag: is one better?
I don't see the relevance of the address you cited above, but if you
are referring to the workaround that I showed you last week --
http://marc.info/?l=php-generalm=131281548332245w=2
-- you can easily extend the technique to set both flags.
header('Set-Cookie: cookie_name=value; secure; HttpOnly');
Andrew
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
