[PHP] redirect http to https
What's the prescribed method for redirecting a user forcibly to from
the non-SSL secured version of a page to the SSL-secured version? Is
this handled at the web server level or at the script level. I found
this by googling:
?php
if($_SERVER['SERVER_PORT'] !== $encport || $_SERVER['HTTPS'] !== on)
{header(Location: https://.$_SERVER['SERVER_NAME'].$_SERVER
['SCRIPT_NAME']);exit;}
?
What do people think about this solution?
Thanks,
- Ben
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] redirect http to https
On 4/9/07, Martin Marques martin@bugs.unl.edu.ar wrote: This should be done with the rewrite instruction of apache, or what ever instructionyour web server has. Um...guess I will have to check with our hosting company about this. Thanks. - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] redirect http to https
On 4/9/07, Peter Lauri [EMAIL PROTECTED] wrote:
You might be able to do this by putting an .htaccess file in your webroot of
non-ssl:
--
RewriteEngine On
RewriteRule ^/(.*)$ https://www.yourdomain.com/$1 [L]
--
This appears to work:
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [L,R]
(sorry if off-topic)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] open source zip code geographical drill down
I'm trying to build some functionality commonly seen on the web where a user enters a zip code and they are provided with a listing of business or entity locations sorted by geographical distance. I've got a client with a distributor network and I need to create something like this for them. They want an end user to be able to enter a zip code and have a list of closest distributors be listed. Anyone know of any open source, free code to get this done. I have a zip code database and can perform a query on it and return the relevant records. I can even associate distributors with certain zip codes, but the whole geographical distance thing is beyond me. Anybody do this before and have advice? Thanks for any guidance here. Regards, Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] creating a threaded message system--sorting messages
On Jun 30, 2006, at 12:05 AM, Larry Garfield wrote: I've written such a system before more than once. You do the sorting in SQL, and then traverse the data recursively in PHP to build the tree. It's a single SQL query. Check the archives for this list for about 3-4 weeks ago, I think. We were just discussing it, and I showed some basic code examples. :-) -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 Did you mean this thread, Larry? -- http://news.php.net/php.general/238478 (on menus and submenu generation) Seems pretty identical to what I'm trying to do. Thanks and disregard my previous post if this is so. - Ben smime.p7s Description: S/MIME cryptographic signature
Re: [PHP] creating a threaded message system--sorting messages
Hi Larry, Thanks for the help. I was just coming to a similar conclusion last night after reading the warnings on this thread about querying the database recursively. I guess my test data with 7 posts is not a rigorous simulation. :-) I've looked through the posts on the PHP general list going back about 3-6 weeks and can't find the thread you speak of. I searched by your name assuming that you posted into the thread and searched by the string recursive and recursion. If you could steer me to it in some other way (subject of the thread or subject word) I would appreciate it, but only if it is not too much trouble. I can take a go at it now that the basic approach is carved out: query once, recurse the data in PHP. Thanks, Ben On Jun 30, 2006, at 12:05 AM, Larry Garfield wrote: I've written such a system before more than once. You do the sorting in SQL, and then traverse the data recursively in PHP to build the tree. It's a single SQL query. Check the archives for this list for about 3-4 weeks ago, I think. We were just discussing it, and I showed some basic code examples. :-) -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 smime.p7s Description: S/MIME cryptographic signature
Re: Re: [PHP] Re: creating a threaded message system--sorting messages
Thanks to everybody who posted on this thread. I wanted to post back
the solution I came up with after removing the DB query from the
recursion. In case anyone else is trying to accomplish the same thing,
this is how I solved it (criticisms welcome, and note that I have not
tested it extensively yet):
DB structure
table: discussion_posts
post_id (auto increment, unique, primary index)
parent_id (post_id corresponding to this post's parent)
discussion_id (to allow multiple discussions, not required but I added
a discussions
member_id (to identify the post to the particular member posting the post)
table as well to store the discussion description and unique ID for
each discussion)
dt_posted (date/time the post was posted)
subject (title of the particular post)
post_text (substance of the post)
So the user selects a particular discussion from a list of
discussions. We query the database for the post_id of the first post
in the discussion requested, this post will have a parent_id of '0' or
NULL since it has no parent. We then query the DB for all the posts in
the discussion joining the members table using member_id to grab the
member's first and last name (or any other member info desired). We
order this query info by dt_posted.
We then write the contents of our second query into a two-dimensional
array ($workArr):
while ([EMAIL PROTECTED]($result)) {
foreach ($row as $key = $value) {
if ($key==post_id) $numerKey=value;
$workArr[$key][$numerKey]=$value;
}
}
The processing of the threads into proper order looks like this:
function processthread($post_id, $workArr) {
echo ul class=\posting\;
echo h3{$workArr['subject'][$post_id]} (#{$post_id})/h3\n;
echo h4by {$workArr['first_name'][$post_id]}
{$workArr['last_name'][$post_id]} .bull; on .
fixdate($workArr['dt_posted'][$post_id]) . /h4;
echo li{$workArr['post_text'][$post_id]}/li\n;
echo h5reply to this/h5;
// find all children, call itself on those too
foreach ($workArr['post_id'] as $value) {
if ($workArr['parent_id'][$value]==$post_id) {
processthread($workArr['post_id'][$value], $workArr);
} // end if
} // foreach
echo /ul;
}
And somewhere in the HTML, where appropriate, the function
processthread is called for the first time passing it the $post_id
value we determined in the first query (the very first post of the
discussion) and the $workArr array.
Use of unordered lists for design/layout is helpful here since
browsers will by default indent lists within lists and list items
within their respective list. This saves some PHP and CSS troubles if
one were to use div or p structure instead, as I found out.
Apologies for any formatting issues and vagaries about the data
structure and variable naming in this post.
- Ben
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP] Re: creating a threaded message system--sorting messages
On 6/30/06, Adam Zey [EMAIL PROTECTED] wrote:
I think that will work, but there is one huge improvement you can make.
You are making millions of copies of your work array! Not only do you
pass the entire array by value recursively, but foreach makes copies of
the arrays it loops through! So who knows how many copies of the darned
work array are being spawned left and right. This can be a memory leak,
consuming lots of memory until it finishes the recursion.
Yipes!
The first thing you can do is tell the function the array is to be
handled by reference:
function processthread($post_id, $workArr) {
Added your suggestion, works fine.
You never change the work array, I think, so you can just keep referring
back to the original.
yes, that is correct. $workArr is never modified.
The second thing to do is to make the foreach work
on references instead of copies. I actually think that since what we
have in our function is now a reference, the foreach WILL NOT copy it.
Anyone have any ideas on this? Is the foreach loop in fact copying
$workArr? And how could we tell (test for it) if it were?
But if it still does, there is always the fallback of doing a foreach on
array_keys($workArr). Then each $value would be the key, which you'd use
to reference $workArr.
I'm sorry, you lost me here a bit.
Regards, Adam.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: creating a threaded message system--sorting messages
On Jun 30, 2006, at 5:04 PM, Adam Zey wrote:
I mean, do this:
foreach ( array_keys($workArr) as $key ) {
echo $workArr[$key]['foo'];
}
instead of this:
foreach ( $workArr as $key = $value ) {
echo $value['foo'];
}
Okay, I think I get the idea.
So using my code example...
this:
foreach ($workArr['post_id'] as $value) {
if ($workArr['parent_id'][$value]==$post_id) {
processthread($workArr['post_id'][$value], $workArr);
} // end if
would become this?:
foreach (arraykeys($workArr['post_id'] as $key) {
if ($workArr['parent_id'][$key]==$post_id) {
processthread($workArr['post_id'][$key], $workArr);
} // end if
Seems to work just fine. Will take the hamsters running in my brain a
little more time to fully understand it... :-)
Thanks again for all your help.
- Ben
Both let you do the same thing, you just reference data
differently, and the first example involves working with the
original array, so foreach has no chance to copy it. HOWEVER, if my
above supposition about foreach not copying a reference is correct,
you wouldn't need to do this. It's just a backup plan.
Regards, Adam.
smime.p7s
Description: S/MIME cryptographic signature
[PHP] creating a threaded message system--sorting messages
This question might deviate from PHP into the domain of MySQL but I thought best to post here first. I'm building a message board system with PHP/MySQL. I'm trying to present the messages to the users in threaded order rather than flat. I'm having a lot of trouble figuring out how to sort the posts so they appear in the correct threaded order. I don't think I can do this purely with a SQL query. If it can be done this way, please suggest how and I'll take this question to the MySQL list. I think I have figured out the basic logic, I just have no idea how to translate it into code. Also, I may have the logic wrong. Anyhow this is what I have so far: relevant data structure loosely: post_id (unique, autoincrement, primary index) parent_id (if the post is a child, this field contains the post_id of its parent) ... 1) Query the database for all messages under a certain topic, sort by parent_id then post_id 2) Somehow resort the data so that each group of children is directly after their parent. Do this in order of ascending parent_id. Can this be done with usort() and some programatic logic/algorithm? How do you sort groups of items together rather than comparing each array element to the next array element (ie: sorting one item at a time)? Should this be done with a recursive algorithm? Anyone with experience writing code for this type of message board, or implementing existing code? Thanks for any help in advance. - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: creating a threaded message system--sorting messages
On 6/29/06, Adam Zey [EMAIL PROTECTED] wrote: Just throwing an idea out there, but you can do the sorting entirely in the SQL query. The trick is to figure out the best way. The first idea that came to mind (and it sucks, but it works), is a text field with padded numbers separated by dots, and the number is the position in relation to the parent. So, with this: Post 1 Post 3 Post 5 Post 6 Post 4 Post 7 Post 2 Post 8 Now, to the helper field would contain this for each post: Post 1: 1 Post 2: 2 Post 3: 1.1 Post 4: 1.2 Post 5: 1.1.1 Post 6: 1.1.2 Post 7: 1.2.1 Post 8: 2.1 Now, by pure ascii sorting in that field, that would sort out to: Post 1: 1 Post 3: 1.1 Post 5: 1.1.1 Post 6: 1.1.2 Post 4: 1.2 Post 7: 1.2.1 Post 2: 2 Post 8: 2.1 Which is the correct sort order. The depth of the post (how far to indent it?) could be told in PHP by counting the number of periods, or storing it in the database. The indentation part I've already sort of figured out--it uses some php to create a divs-within-divs structure, then using some simple CSS I can get the appropriate level of indentation. Now, how to figure out what to put in that field for each post? We need to do two things. First, each post needs to store the number of children. Next, when a new post is made, we do three things (Keeping in mind that in real life I'd pad each entry in the sort helper field with zeros on the left up to some large number): 1) Get the sort helper field of the parent and the parent's child count field 2) Take the parent's sort help field, and add on a period and the parent's child count plus one, insert the child. 3) Update the parent's child count. OK, now, this method sucks. It's slow, and limits the number of child posts to whatever you pad (In itself, not a big issue, if each post can only have, say, a thousand direct childs (which each themselves can have a thousand childs), not a huge issue). The slow part from ascii sorting everything is the problem, I'd think. I've never done threaded anything before, so I assume there's a better solution. I'm just saying that the job CAN be done entirely with SQL sorting. And probably faster than your proposed method of resorting everything once PHP gets ahold of it. It should be noted that you'd need each post to have a sort of superparent field that stored the topmost parent so that you could do something simple like selecting ten superparents and all their children. Regards, Adam. Thanks for the help Adam, I'll try to wrap my head around your response... - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: creating a threaded message system--sorting messages
SOLVED, almost. I read the article suggested by K.Bear and found the recommended solution to be a bit more complicated than I wanted to implement. I then found another way to do this using the existing Adjacency List Model through a recursive function. So basically, you query the database for the post_id of the very first post in the discussion. You then call a function that displays that post, searches for all children of that post and then calls itself recursively on each of the children it discovers. This works great for spitting out the posts in the proper order. Now I'm trying to figure out how to make sure the indenting looks right in the browser. - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] shutting down a web app for maintenance
Hello All, I'm not sure this is strictly a PHP related question or perhaps a server admin question as well. What do you do when you are trying to shutdown a web application for maintenance (like a membership or registration-required system)? I understand that you can temporarily upload or activate a holding page that prevents users from continuing to login/use the system, but how can you insure that there are no ongoing sessions or users still in the process of doing something? What's the best method for handling this, especially if you don't have full control of the server hosting the web app? Thanks for any advice, - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] shutting down a web app for maintenance
Hi Jon, Thanks for the response. What would these solutions mean in regards to users who are active at the moment that the .htaccess file is added? Would it be wise to force some kind of logout, destruction of open sessions, etc. I guess there is no simple, graceful way to allow users to complete whatever they are doing and then kick them off while preventing new users from logging in. I was thinking for example, what if someone is in the process of uploading a file to the web app host or filling out step 2 of a 4 part membership form or something that requires multiple steps. - Ben On 6/20/06, Jon Anderson [EMAIL PROTECTED] wrote: Assuming you're using a web server that supports htaccess files, you could easily just pop in a .htaccess file that denies access to everything. You could even add a PHP ini directive like: php_value auto_prepend_file maintenance.php where maintenance.php could contain something like: htmlheadtitleDown for Maintenance/title/headbodySite down for maintenance!/body/html ?php exit(0); ? (Or, to be sure, you could do both.) jon Ben Liu wrote: Hello All, I'm not sure this is strictly a PHP related question or perhaps a server admin question as well. What do you do when you are trying to shutdown a web application for maintenance (like a membership or registration-required system)? I understand that you can temporarily upload or activate a holding page that prevents users from continuing to login/use the system, but how can you insure that there are no ongoing sessions or users still in the process of doing something? What's the best method for handling this, especially if you don't have full control of the server hosting the web app? Thanks for any advice, - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: shutting down a web app for maintenance
Thanks Adam, What you say makes good sense to me. Is there some method to run a script that kills all active sessions on a host? It could become part of the maintenance script I suppose: 1) Kill all active sessions 2) Put up generic maintenance screen 3) Deny further login attempts - Ben On 6/20/06, Adam Zey [EMAIL PROTECTED] wrote: Ben Liu wrote: Hello All, I'm not sure this is strictly a PHP related question or perhaps a server admin question as well. What do you do when you are trying to shutdown a web application for maintenance (like a membership or registration-required system)? I understand that you can temporarily upload or activate a holding page that prevents users from continuing to login/use the system, but how can you insure that there are no ongoing sessions or users still in the process of doing something? What's the best method for handling this, especially if you don't have full control of the server hosting the web app? Thanks for any advice, - Ben I normally do what you say; activate a holding page. The question comes to mind, does it really matter if a user's session is interrupted? Is the web application dealing with data that is critical enough (or non-critical data in a possibly destructive manner) that you can't just cut them off for a while? You have to consider that users could just as easily be cut off by a server crash, packetloss/network issues (on your end OR theirs, or anywhere in between), or just might hit the stop button while a script is running (Which, IIRC, ordinarily terminates the script the next time you try to send something). If your web app works in a way such that you can't just pull the plug and everything is fine, you're running some pretty big risks that your app will get into unrecoverable states from everyday issues. If you wanted to get fancy, you could code your system to prevent new logins, expire normal logins much faster (Say, after 15 minutes instead of hours or days), and then wait for all users to be logged out before continuing. Regards, Adam Zey. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: shutting down a web app for maintenance
On 6/20/06, Adam Zey [EMAIL PROTECTED] wrote: Shutting down Apache would do the trick ;) But if you're in a shared hosting environment that may not be possible. Yeah, don't have full control over the server in this case. As for sessions, it depends how you track them. You can't kill all PHP sessions in one go, but you could have your web app nuke the sessions of users after they come back after maintenance. Something like first_login_after_maint in the database, that if set to true, mandates that any existing session data be destroyed before continuing. How about iterating through the /tmp directory and deleting all the session cookies? On second thought, that would kill all the sessions for other apps as well. I assume that the reason you want to kill session data is because the data and how it is used would be different after the maintenance? Because otherwise, if you've denied all access to ANY of your webapp's php scripts, it shouldn't matter if the user has session data. If you physically move the web app's PHP scripts (Or set up a redirect, etc), they can't do anything with it. I didn't have a specific reason for doing it, just wasn't sure what the ramifications of having open sessions alive through the maintenance period and afterward might be so I thought it best to just kill them. It doesn't sound like anything horrible can happen except some inconvenience maybe. Regards, Adam Ben Liu wrote: Thanks Adam, What you say makes good sense to me. Is there some method to run a script that kills all active sessions on a host? It could become part of the maintenance script I suppose: 1) Kill all active sessions 2) Put up generic maintenance screen 3) Deny further login attempts - Ben On 6/20/06, Adam Zey [EMAIL PROTECTED] wrote: Ben Liu wrote: Hello All, I'm not sure this is strictly a PHP related question or perhaps a server admin question as well. What do you do when you are trying to shutdown a web application for maintenance (like a membership or registration-required system)? I understand that you can temporarily upload or activate a holding page that prevents users from continuing to login/use the system, but how can you insure that there are no ongoing sessions or users still in the process of doing something? What's the best method for handling this, especially if you don't have full control of the server hosting the web app? Thanks for any advice, - Ben I normally do what you say; activate a holding page. The question comes to mind, does it really matter if a user's session is interrupted? Is the web application dealing with data that is critical enough (or non-critical data in a possibly destructive manner) that you can't just cut them off for a while? You have to consider that users could just as easily be cut off by a server crash, packetloss/network issues (on your end OR theirs, or anywhere in between), or just might hit the stop button while a script is running (Which, IIRC, ordinarily terminates the script the next time you try to send something). If your web app works in a way such that you can't just pull the plug and everything is fine, you're running some pretty big risks that your app will get into unrecoverable states from everyday issues. If you wanted to get fancy, you could code your system to prevent new logins, expire normal logins much faster (Say, after 15 minutes instead of hours or days), and then wait for all users to be logged out before continuing. Regards, Adam Zey. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: order of elements in $_POST super global
Hi Richard,
I'm basically building a custom mysql table to delimited text file
function for a membership site. So I've got a lot of typical
demographic info fields like name, address, etc. The site owners
would like to dump the membership information for their own purposes,
but they don't always want a complete set of all data. So the form
lists each field with a checkbox to determine whether it is desired
in the exported text file. To simplify things, the names of the
checkbox form fields correspond exactly to the names of the related
fields in the mysql table. So if there is a field named
home_address1, the form checkbox is also name=home_address1. When I
capture the form data, I iterate through the $_POST variable and
create a custom query based on the checkboxes that are checked. So
the form presented looks like:
snip
input type=checkbox value=1 name=prefixPrefix/inputbr
/
input type=checkbox value=1 name=first_nameFirst Name/
inputbr /
input type=checkbox value=1 name=middle_nameMiddle Name/
inputbr /
input type=checkbox value=1 name=last_nameLast Name/
inputbr /
input type=checkbox value=1 name=suffixSuffix/inputbr
/
input type=checkbox value=1 name=home_addr1Home Address
(Street)/inputbr /
input type=checkbox value=1 name=home_addr2Home Address 2/
inputbr /
/snip
Since the form fields names correspond to mysql field names rather
than just a plain index array, I can use the keys thus:
snip
$exp_format=array_shift($_POST);
if ($exp_format==tab) {$delimiter=\t; $filesuffix=.txt;}
if ($exp_format==csv) {$delimiter=,; $filesuffix=.csv;}
/* reset three array elements in the POST superglobal, they are
flags and
should not be part of the custom query */
$mem_activity=array_shift($_POST);
$part_pref=$_POST['part_pref'];
unset($_POST['part_pref']);
$query=SELECT mem_id, ;
foreach ($_POST as $key = $data) {
$query.=$key, ;
}
/* chops off the last space and comma */
$length=strlen($query);
$query=substr($query, 0, $length-2);
/snip
So what I really want to know is if there is some kind of best-
practice method of rearranging the order of the items in a $_POST
array without rearranging the elements on the original form, or post-
processing them item by item.
Thanks for any insights...
- Ben
The script that processes the form looks like:
On Jun 9, 2006, at 7:12 PM, Richard Lynch wrote:
name=bool[0][careers]
might do what you want...
it's really quite difficult to say without a concrete example...
On Thu, June 8, 2006 10:20 am, Ben Liu wrote:
I probably should add some more details to my question:
The names of the form checkboxes could be changed from ie:
bool_careers, bool_speaking, bool_internship, etc. to a single array
bool_questions[], for instance. The problem with that is that I am
using the form checkbox names later to process related data.
Specifically, I am building a user-input based query. So if the form
checkbox names are the same as the names of the variables in the
database, it makes for easy creating of the query, since the names
become associative keys in the $_POST array. I iterate through the
$_POST array, checking each for true/false state. If the checkbox is
checked, I add the associative key name to the query. Eliminating the
checkbox names in favor of a numerical key only would make this more
complicated.
- Ben
On 6/8/06, Barry [EMAIL PROTECTED] wrote:
1. Use Keys in your form like a[1],a[2]
2. order the array by usort (alphabetically or whatever u prefer)
that way = 2: yes it is.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Like Music?
http://l-i-e.com/artists.htm
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP] Re: order of elements in $_POST super global
Hi Mike, Thanks for pointing that out. I hadn't thought of it but you are right. But I still don't think this addresses the issue of ordering. The basic problem is that the way a $_POST variable gets processed is in the order it is in on the original form. If you want to present the fields in one manner and process them in a different order, you have to either use styling tricks to change the presentation order or use some post processing to change the order of the array or use potentially a ton of if statements or as Joao suggests, a long switch statement. Anyhow, thanks for the tip. - BL On 6/9/06, Ford, Mike [EMAIL PROTECTED] wrote: I know you've found another (perfectly good) solution already, but I just wanted to point out that you could have used the above scenario with the names as the array indexes, like: input type=checkbox name=bool_questions[first_name] value=yes The above input shows up in $_POST['bool_questions']['first_name'], so you could iterate over $_POST['bool_questions'] to get the result you want. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: order of elements in $_POST super global
Hi Mindaugas, I wasn't trying to imply that there was something wrong or illogical about the way the $_POST variable is processed. It is logical that it processes in the order listed in html. Perhaps I should have said, my problem rather than the problem. I'll be sure to read about the bug you mention. Thanks. - BL On Jun 9, 2006, at 8:54 AM, Mindaugas L wrote: Hello, The basic problem is that the way a $_POST variable gets processed is in the order it is in on the original form. I think it's very natural behaviour. But be careful with associative arrays, I think before version 5.12.there was a bug, if you want that PHP makes an associative array of form elements. http://bugs.php.net/bug.php?id=37276 Enjoy Mindaugas On 6/9/06, Ben Liu [EMAIL PROTECTED] wrote: Hi Mike, Thanks for pointing that out. I hadn't thought of it but you are right. But I still don't think this addresses the issue of ordering. The basic problem is that the way a $_POST variable gets processed is in the order it is in on the original form. If you want to present the fields in one manner and process them in a different order, you have to either use styling tricks to change the presentation order or use some post processing to change the order of the array or use potentially a ton of if statements or as Joao suggests, a long switch statement. Anyhow, thanks for the tip. - BL On 6/9/06, Ford, Mike [EMAIL PROTECTED] wrote: I know you've found another (perfectly good) solution already, but I just wanted to point out that you could have used the above scenario with the names as the array indexes, like: input type=checkbox name=bool_questions[first_name] value=yes The above input shows up in $_POST['bool_questions'] ['first_name'], so you could iterate over $_POST['bool_questions'] to get the result you want. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Mindaugas smime.p7s Description: S/MIME cryptographic signature
[PHP] order of elements in $_POST super global
Hello All, I'm using a form (method=POST) to collect 30 boolean values from the end user using a series of checkboxes in the form. The form is arranged in a table so that the 30 check boxes are not a long list but rather three columns (with related items columnized). The problem is when I iterate through the $_POST results: The order in which I wish to present the checkboxes to the end user is different than the order I want to have in the $_POST super global and subsequently when I dump that information out to a text file. What would be the best way to solve this? 1) Is there a way to present the checkboxes in a certain order, yet have the data transmitted into the $_POST super global in a different order? 2) Does it make more sense to process the $_POST super global array and reorder the items within the array? 3) Some other method? Thanks for any advice. - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] order of elements in $_POST super global
Hi Dave, No, that is definitely a possibility. Right now I am using a foreach loop to iterate over the $_POST array and determine if each checkbox is checked or not, if it is checked, than a related piece of data is written into the text file. This makes for pretty compact code. I could as you suggest, simply check each element in the array manually using the associative keys rather than using a loop, that way I could do it in any order I wished, but the code gets rather long with a line for each checkbox. I anticipate this set of checkboxes/boolean responses may increase in the future also, so having the loop allows for some future-proofing. - Ben On 6/8/06, Dave Goodchild [EMAIL PROTECTED] wrote: On 08/06/06, Ben Liu [EMAIL PROTECTED] wrote: You can access the values in the $_POST array in any order, so if you know the checkbox names why not output them in the order you want? Or I am being dumb here? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: order of elements in $_POST super global
I probably should add some more details to my question: The names of the form checkboxes could be changed from ie: bool_careers, bool_speaking, bool_internship, etc. to a single array bool_questions[], for instance. The problem with that is that I am using the form checkbox names later to process related data. Specifically, I am building a user-input based query. So if the form checkbox names are the same as the names of the variables in the database, it makes for easy creating of the query, since the names become associative keys in the $_POST array. I iterate through the $_POST array, checking each for true/false state. If the checkbox is checked, I add the associative key name to the query. Eliminating the checkbox names in favor of a numerical key only would make this more complicated. - Ben On 6/8/06, Barry [EMAIL PROTECTED] wrote: 1. Use Keys in your form like a[1],a[2] 2. order the array by usort (alphabetically or whatever u prefer) that way = 2: yes it is. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: order of elements in $_POST super global
Also, I need to re-order the elements in a custom manner, not simply alphabetical or reverse alphabetical or some logical way like that, more like how the original form is presented, by related fields. More specifically, the form is for a membership system, the system collects typical demographic information like home street address, home zip code, business street address, business zip code. So the form presents related fields together: business with business fields and home with home fields (in columns). The problem is the POST method writes these response into the $_POST array in a certain order: not top-to-bottom, then left-to-right as a person would read the form, but left-to right, then top-to-bottom. The simple solution would be to reorder the form checkboxes so that they matched the desired output order of the text file, but then the user is presented with a disorganized, illogical form. I could eliminate the table and just list all the checkboxes in one big list, but again that makes for an ugly, user-unfriendly form. I could perhaps use some divs to make columns and float them, I'm not sure how the $_POST method would order the responses in the $_POST array. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] order of elements in $_POST super global
Der...of course. Thanks Ron! I knew the answer was simple. :-)
-Ben
On 6/8/06, Ron Clark [EMAIL PROTECTED] wrote:
why not create an array with the keys in the order you want ( $array=
array(value1,value2,). Then loop through the array and use the
values as keys to the $_POST variable and perform your processing that way.
foreach ($array as $value) {
if (isset($_POST[$value]) {
do something;
}
}
--
Ron Clark
System Administrator
Armstrong Atlantic State University
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: order of elements in $_POST super global
Hello João,
You are right that the $_POST variable does not receive anything for
unchecked boxes. I didn't realize that. But I still need the foreach
loop for other reasons:
So it looks like this:
foreach ($_POST as $key = $data) {
$query.=$key, ;
}
Instead of this:
foreach ($_POST as $key = $data) {
if ($data) $query.=$key, ;
}
Thanks,
Ben
On 6/8/06, João Cândido de Souza Neto [EMAIL PROTECTED] wrote:
Since i remember, when a for POST is sent and a checkbox is not checked, php
not receive this $_POST variable.
That is, i think you don´t need to use a foreach to know if checkbox was
checked or not.
Am i wrong?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: order of elements in $_POST super global
yes, as I said in an earlier post, I used to have 30 if ($key)
statements, one for each checkbox, in the order I wanted to write them
in. This is not optimal because: (a) it is a ton of code, (b) the
checkboxes could in the future increase in number, change order, etc.
and then I would have to recode this section to match. The solution I
used to solve this was to remove the table, put all the checkboxes
into div elements, float them into columns and now they appear in
the same order as before when they were in a table, but they write to
the $_POST variable in the order that I want.
- Ben
On 6/8/06, João Cândido de Souza Neto [EMAIL PROTECTED] wrote:
I don´t test, but it can works fine:
foreach ($_POST as $key = $data) {
switch ($key) {
case aaa
$query.=$key, ;
break;
case bbb
$query.=$key, ;
break;
case ccc
$query.=$key, ;
break;
}
}
In switch you can order by ordening the cases.
Hope help.
- Original Message -
From: Ben Liu [EMAIL PROTECTED]
To: João Cândido de Souza Neto [EMAIL PROTECTED]
Cc: php-general@lists.php.net
Sent: Thursday, June 08, 2006 1:14 PM
Subject: Re: [PHP] Re: order of elements in $_POST super global
Hello João,
You are right that the $_POST variable does not receive anything for
unchecked boxes. I didn't realize that. But I still need the foreach
loop for other reasons:
So it looks like this:
foreach ($_POST as $key = $data) {
$query.=$key, ;
}
Instead of this:
foreach ($_POST as $key = $data) {
if ($data) $query.=$key, ;
}
Thanks,
Ben
On 6/8/06, João Cândido de Souza Neto [EMAIL PROTECTED] wrote:
Since i remember, when a for POST is sent and a checkbox is not checked,
php
not receive this $_POST variable.
That is, i think you don´t need to use a foreach to know if checkbox was
checked or not.
Am i wrong?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] reset a resource?
sorry, mysql_data_seek()
On 6/8/06, sam [EMAIL PROTECTED] wrote:
After I've looped through a resource do I have to run the query again
to load up 'mysql_fetch_assoc' or is there some kind of reset
function I can't find?
$q = SELECT * FROM table;
$s = mysql_query($q, $pe) or die(mysql_error());
while ($row_s = mysql_fetch_assoc($s)) {
echo $i++;
}
outputs 12345... for each row of table
while ($row_s2 = mysql_fetch_assoc($q)) {
...
}
outputs
Thanks
--
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] better way to create custom text file from query results?
Hello All, I've written a clunky script that presents a form to a user with 30 checkboxes on it to match 30 fields in a table. The user checks off each field they want to appear in a text file produced by the script. The script I wrote captures each checkbox response to a separate variable: $fieldname1=$_POST['fieldname1']; $fieldname2=$_POST['fieldname2']; etc... I then build a custom query based on those variables using 30 logic statements like such: if ($fieldname1) $query .=fieldname1, ; if ($fieldname2) $query .=fieldname2, ; etc... I then query the DB and iterate over the results, shoving the data into an output variable like this (again 30 logic statements): if ($fieldname1) $output.=$row[fieldname1]\t; if ($fieldname2) $output.=$row[fieldname2]\t; then I print the contents of $output to a text file. It seems that there has to be a better way of doing this. Can the $_POST superglobal be manipulated in this way: foreach ($_POST as $fieldname) ? Thanks for any help and guidance. - Ben smime.p7s Description: S/MIME cryptographic signature
Re: [PHP] better way to create custom text file from query results?
I guess I was just talking the problem out. :-)
Writing that post helped me think of iterating through $_POST. Now
I've come to this problem:
Before I did this and it works:
while ([EMAIL PROTECTED]($result)) {
if ($fieldname1) $output.=$row[fieldname1]\t;
if ($fieldname2) $output.=$row[fieldname2]\t;
}
Trying to tighten up as discussed with this, but doesn't work:
while ([EMAIL PROTECTED]($result)) {
foreach ($_POST as $key = $data)
if ($data) {$output.=$row[ . $key . ]\t;
} // foreach
} // end while $row
The above throws a Parse error: parse error, expecting `T_STRING' or
`T_VARIABLE' or `T_NUM_STRING' in error.
This substitution:
if ($data) {$output.=$row[$key]\t;
eliminates the aforementioned error, but does not produce the desired
results.
On Jun 7, 2006, at 8:26 AM, chris smith wrote:
If in doubt give something a try. :)
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP] better way to create custom text file from query results?
Nevermind, got it to work with this:
while ([EMAIL PROTECTED]($result)) {
foreach ($_POST as $key = $data) {
if ($data) $output.=$row[$key]\t;
} // foreach $_POST
}// while $row
Had a poorly positioned statement throwing off the data output.
Thanks for all suggestions...
--Ben
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP] Session contamination?
Yes, Chuck is correct here. The security issue I raised has to do with multiple users on the same shared server, which is how some hosting companies manage their clients. Each user may have a different home directory and has separation from other users, however, usually the same /tmp directory is used to store all the session cookies for all the users on the server. By running a simple script in your area you can read all the sessions managed by the server including sessions generated by other users. By moving the session cookies to a directory within your own user area it may make them more difficult to find, but it does not guarantee security as Chuck points out. This is discussed at [http://php.net/manual/en/ ref.session.php] as pointed out by Jochem. - Ben On Apr 20, 2006, at 7:22 PM, Richard Lynch wrote: On Thu, April 20, 2006 1:46 pm, Ben Liu wrote: After a bit more research, I think I understand why Jochem recommends use of session_save_path() rather than just naming each session differently. The former method provides more security as you can set the location where session cookies are stored. This will help prevent an attacker from gaining access to session information and then using it to gain inappropriate access to the application the session was created for or even other applications running on the same shared server. Anyway, I think that's why. ::Possible False Sense Of Security Alert:: If a Bad Guy can read the session data, moving it to a different directory is probably not going to help, really... Unless you are running with different Usernames for each client on your shared server, using FastCGI + suexec or some similar method, the cookie files are STILL just as readable by the same Bad Guys, using the same methods. They just have to change their to: ?php $path = /other/path/to/other/cookies;? before they start their damage. There may well be other GREAT reasons for using a different save path, or a different path for the Cookie, or session_name over each other, but I don't think Security is the reason behind any of the choices. I'd personally use ini_set as the last choice because it's remotely possible that the setting can't be changed from within a script, as a few are like that -- Or, worse, that they can be changed today, but in, say PHP 6 or PHP 7, they won't be for some obscure reason we cannot predict today. session_name() seems less likely to just disappear completely as a feature than a minor change to a php.ini setting and where it is allowed. But that's just my paranoid logic. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Ach, correction: Chuck is correct here. = *Richard* is correct here. No morning coffee yet, sorry. - Ben On Apr 20, 2006, at 7:22 PM, Richard Lynch wrote: On Thu, April 20, 2006 1:46 pm, Ben Liu wrote: After a bit more research, I think I understand why Jochem recommends use of session_save_path() rather than just naming each session differently. The former method provides more security as you can set the location where session cookies are stored. This will help prevent an attacker from gaining access to session information and then using it to gain inappropriate access to the application the session was created for or even other applications running on the same shared server. Anyway, I think that's why. ::Possible False Sense Of Security Alert:: If a Bad Guy can read the session data, moving it to a different directory is probably not going to help, really... Unless you are running with different Usernames for each client on your shared server, using FastCGI + suexec or some similar method, the cookie files are STILL just as readable by the same Bad Guys, using the same methods. They just have to change their to: ?php $path = /other/path/to/other/cookies;? before they start their damage. There may well be other GREAT reasons for using a different save path, or a different path for the Cookie, or session_name over each other, but I don't think Security is the reason behind any of the choices. I'd personally use ini_set as the last choice because it's remotely possible that the setting can't be changed from within a script, as a few are like that -- Or, worse, that they can be changed today, but in, say PHP 6 or PHP 7, they won't be for some obscure reason we cannot predict today. session_name() seems less likely to just disappear completely as a feature than a minor change to a php.ini setting and where it is allowed. But that's just my paranoid logic. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session contamination?
Hi Chuck, Glad this discussion has been of use to you. I can't help much with where your /tmp directory might be. if you echo session_save_path() it should tell you where your session cookies are being saved to on your server. I have read recommendations that you set a different path for the cookies using session_save_path(), and yes they recommend some place within your home directory structure. The problem this creates is in garbage collection. The standard *nix cron jobs will clear everything out of /tmp on a regular basis whereas some directory you create will not be subject to this regular housekeeping unless you write some script to do it or create a custom cron job. My interpretation of managing this problem, at this point is: If you are on a shared server and have an application or applications that have sensitive data and require an adequate level of security, you should move the session cookies somewhere away from /tmp and dealing with the garbage collection issues. Alternatively, perhaps you shouldn't be using shared hosting or you could encrypt the sessions cookies somehow. If you are on a shared server and don't have sensitive data, changing the session name should be enough to prevent cross-contamination of session variables. I'm still reading/learning so if I'm wrong, someone else please jump in. - Ben On Apr 21, 2006, at 12:05 AM, Chuck Anderson wrote: This has been a very interesting discussion, as I have had the same problem, but never thought much about the fact that I could do anything about it. As to session save path, when I run phpinfo (at my remote Linux server) it tells me that it is set to no value. This means it would default to /tmp. Where is this tmp directory? I have looked at the tmp directory that is one level above my site's www directory (outside of the web space), but I do not see any session data there. That's why I am asking if it is a system wide directory, or is it the one in my home directory. If I set the path myself, what would be a good location? (I assume it should be outside the web space). Should I make up some random folder name (one time) and story my session data within that directory, within my own home directory? Ben Liu wrote: Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? What is the best way to avoid/prevent this problem? Should I be using specific Session ID's or Session names? Thanks for any help, - Ben -- * Chuck Anderson • Boulder, CO http://www.CycleTourist.com Integrity is obvious. The lack of it is common. * -- 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] Session contamination?
Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? What is the best way to avoid/prevent this problem? Should I be using specific Session ID's or Session names? Thanks for any help, - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Thanks for the response Robin, I'm reading up on session.cookie_path now. It seems that this would require creating separate php.ini files for each application. On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote: On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? Yes - that's the default behaviour, although if you set session.cookie_path separately for each app, they shouldn't share session cookies. You might also want to look at session.save_path which will allow each app to save their session files in a different location. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Hi Dave, Thanks, I think the method recommended by Robin using the function ini_set() would work, but somehow I think this could be done in simpler fashion by setting separate session names for each app, unless I am misunderstanding the use of session_name(). Trying this out now... - Ben On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote: You can use ini_set to alter this value locally (until the script exits) in the script itself, which saves having to use a separate ini file if that is the only value you want to change. On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Thanks for the response Robin, I'm reading up on session.cookie_path now. It seems that this would require creating separate php.ini files for each application. On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote: On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? Yes - that's the default behaviour, although if you set session.cookie_path separately for each app, they shouldn't share session cookies. You might also want to look at session.save_path which will allow each app to save their session files in a different location. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- http://www.web-buddha.co.uk dynamic web programming from Reigate, Surrey UK look out for project karma, our new venture, coming soon! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Thanks Jochem, this should give me all I need to solve this problem. -Ben
On 4/20/06, Jochem Maas [EMAIL PROTECTED] wrote:
Ben Liu wrote:
Hi Dave,
Thanks, I think the method recommended by Robin using the function
ini_set() would work, but somehow I think this could be done in
simpler fashion by setting separate session names for each app, unless
I am misunderstanding the use of session_name(). Trying this out
now...
passing a different/unique value to session_name() should avoid inadvertent
contamination.
[http://php.net/manual/en/function.session-name.php]
Robin's second suggestion of setting the save path can be done with
session_save_path() as well as via ini_set().
[http://php.net/manual/en/function.session-save-path.php]
Robin's first suggestion is the one I would implement first, you can set the
[url]path for which a given session is valid by way of the
session_set_cookie_params()
function, the path can also be set via ini_set('session.cookie_path',
'/my/app/example')
note that session_name() and session_save_path() must be called before you
call session_start()
I recommend going through the info at http://php.net/manual/en/ref.session.php
in order to get a better 'feel' of how to use sessions 'properly'
- Ben
On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote:
You can use ini_set to alter this value locally (until the script exits) in
the script itself, which saves having to use a separate ini file if that is
the only value you want to change.
On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote:
Thanks for the response Robin, I'm reading up on session.cookie_path
now. It seems that this would require creating separate php.ini files
for each application.
On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote:
On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote:
Hello All,
I'm using a single development server to host multiple client
projects, many of which require session management. I've noticed that
sometimes when I test these various web apps (which are simply in
separate sub directories) I get session leakage where logging in and
establishing a session on one app allows me access to (automatically
logs me in) to other app(s) on the same server. Or sometimes a session
variable will be set across all the apps, like $_SESSION['username'].
Is this due to the fact that sessions are established between client
browsers and servers, regardless of directory/sub directory?
Yes - that's the default behaviour, although if you set
session.cookie_path separately for each app, they shouldn't share
session cookies. You might also want to look at session.save_path
which will allow each app to save their session files in a different
location.
-robin
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
http://www.web-buddha.co.uk
dynamic web programming from Reigate, Surrey UK
look out for project karma, our new venture, coming soon!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Hi Dave, After a bit more research, I think I understand why Jochem recommends use of session_save_path() rather than just naming each session differently. The former method provides more security as you can set the location where session cookies are stored. This will help prevent an attacker from gaining access to session information and then using it to gain inappropriate access to the application the session was created for or even other applications running on the same shared server. Anyway, I think that's why. - Ben On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote: Let me know how you get on. I have encountered the session leakage issue before also and it scared the willies out of me. On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hi Dave, Thanks, I think the method recommended by Robin using the function ini_set() would work, but somehow I think this could be done in simpler fashion by setting separate session names for each app, unless I am misunderstanding the use of session_name(). Trying this out now... - Ben On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote: You can use ini_set to alter this value locally (until the script exits) in the script itself, which saves having to use a separate ini file if that is the only value you want to change. On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Thanks for the response Robin, I'm reading up on session.cookie_path now. It seems that this would require creating separate php.ini files for each application. On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote: On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? Yes - that's the default behaviour, although if you set session.cookie_path separately for each app, they shouldn't share session cookies. You might also want to look at session.save_path which will allow each app to save their session files in a different location. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- http://www.web-buddha.co.uk dynamic web programming from Reigate, Surrey UK look out for project karma, our new venture, coming soon! -- http://www.web-buddha.co.uk dynamic web programming from Reigate, Surrey UK look out for project karma, our new venture, coming soon! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] AJAX PHP
I've been tinkering with AJAX for a few weeks now. I've used it in a simple user registration system form. Instead of submitting a desired username and waiting for a round trip to the server to verify that the username is not already in use, I used AJAX to perform the DB query in the background without a browser refresh. It is pretty slick, using a little CSS and javascript the user gets instant notification (onblur) that their selected username is already in use or is verified and okay before submitting the rest of the form. I implemented this with XML, however, only to learn, not because the functionality required it. I've also accumulated some links to resources: http://www.ajaxmatters.com http://www.ajaxpatterns.org http://adaptivepath.com/publications/essays/archives/000385.php (This is the essay that coined the term 'AJAX') http://www.ajaxian.com The above links all have good collections of links to further resources. Good Luck, ... Benjamin Liu On Jul 21, 2005, at 1:52 AM, balwant singh wrote: Have anybody tried PHP AJAX, may please share your experience. also pls. suggest good link of tutorial on this. With Best Wishes Balwant Singh -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
