Jump to content

Correct User-Friendly URL Appears, But Bad GET Value Is Processed


Go to solution Solved by kicken,

Recommended Posts

Hi All,

 

I have a series of subscription forms that works well in a non-url rewriting context.

 

When the user clicks a link (with href of type "subscription.php?id=new"), a form appears with country names in it. Then when the user clicks a country name (with href of type "subscription.php?country=ID_000_AAA", where 0 and A represent respectively a digit and an uppercase letter), a new form appears adapted to the country chosen.

 

I tried to convert this into an url rewriting context, and here is the problem. When the user clicks a country name, the country names form displays again. Despite the fact that the address bar contains the url rewriting version of the clicked link, a print_r($_GET) shows that it is still the GET parameter/value pair from the first form that is processed, not the GET parameter/value pair for the country clicked.

 

Thanks for your help.

 

PS/BTW, does [.*] include underscores ?

 

 

 

 

RewriteRule fr/member-subscription.html fr/newmember.php?id=newmember
RewriteRule fr/member-subscription.html?country([.*]) fr/newmember.php?ctry_data$1

where ([.*]) is "=country_code" as explained above

 

(Actually page names are nearer to French reading, but I "translated" them for -hopefully- better understanding.)

 

  • Solution

Query strings are not part of the URL when it comes to matching with RewriteRule. To match the query string you need to use RewriteCond on the %{QUERY_STRING} variable.

 

Also rules are proccessed in order, so if you have overlapping matches you need to ensure to order them most-specific to least-specific. So you want to match against fr/member-subscription.html?country first, then if that fails match against fr/member-subscription.html. Since there's no need for them to chain together either, stick a LAST flag on them also to prevent further processing.

 

RewriteCond %{QUERY_STRING} country=(.*)
RewriteRule fr/member-subscription.html fr/newmember.php?ctry_data=%1 [L]

RewriteRule fr/member-subscription.html fr/newmember.php?id=newmember [L]

Great, kicken ! You saved my week-end and nerves...

 

Suppose there is a third form for payment, would I need two RewriteCond blocks (with the payment block as the first block I guess), or is it possible to do something like this :

RewriteCond %{QUERY_STRING} payment=ok country=(.*)
RewriteRule fr/member-subscription.html fr/newmember.php?give_me_your_money=%1 [L]
RewriteRule fr/member-subscription.html fr/newmember.php?ctry_data=%2 [L]
RewriteRule fr/member-subscription.html fr/newmember.php?id=newmember [L]

If your query string looked like country=...&payment=ok then you'd need to match against that format. You could do it either as two separate conditions or a single condition.

 

#matches fr/member-subscription.html?country=...&payment=ok
RewriteCond %{QUERY_STRING} country=([^&]*)&payment=ok
RewriteRule fr/member-subscription.html fr/newmember.php?give_me_your_money=%1 [L]
or

#matches fr/member-subscription.html?payment=ok&country=... 
#also matches fr/member-subscription.html?country=...&payment=ok
#and other variations
RewriteCond %{QUERY_STRING} payment=ok
RewriteCond %{QUERY_STRING} country=([^&]*)
RewriteRule fr/member-subscription.html fr/newmember.php?give_me_your_money=%1 [L]

If your payment / country parameters are separate rather than together then you'd just do separate rule/conditions pairs

#matches fr/member-subscription.html?payment=ok
RewriteCond %{QUERY_STRING} payment=ok
RewriteRule fr/member-subscription.html fr/newmember.php?give_me_your_money=ok [L]

#matches fr/member-subscription.html?country=...
RewriteCond %{QUERY_STRING} country=(.*)
RewriteRule fr/member-subscription.html fr/newmember.php?ctry_data=%1 [L]
  • Like 1

Hi All,

 

I have another problem now... I am losing $_SESSION variables. Once the user clicks a country name, some $_SESSION variables are created for that country, then a form with a series of fields appears. A $_SESSION vardump at the beginning of that new form shows that those country variables have been created.

 

For URL rewriting purposes I set the form tag as

<form method="post" action="/[domain]/fr/member-subscription.html">

and added

RewriteRule fr/member-subscription.html fr/newmember.php [L]

to the .htaccess file. When the user submits the form, the process fails. At every stage in newmember.php, I do some checking, and in case of failure, the $_SESSION and $_POST contents are stored in a txt file, together with the line number in newmember.php where the failure occurred. The POST part of that file contains the fields of the form, which means that the form has been loaded. However the SESSION part lacks the variables created once the user clicks a country name in the country list form. (Variable created before the displaying of the country list form still exist). newmember.php did its jobs, since it only processes the form if the SESSION variables about the country chosen exist, hence the failure. This does not happen if I do not use URL Rewriting.

I guess there is something wrong in the following setting :

RewriteCond %{QUERY_STRING} country=(.*)
RewriteRule fr/member-subscription.html fr/newmember.php?ctry_data=%1 [L]
RewriteRule fr/member-subscription.html fr/newmember.php?id=newmember [L]

RewriteRule fr/member-subscription.html fr/newmember.php  [L]

Thanks !

URL rewriting shouldn't affect your sessions. The only way it might is if you were passing the session ID via the URL but that is not recommended and not typical.

 

Check the request using the browsers dev tools or extra logging ($_COOKIE) in PHP to make sure the session ID is being passed properly in the request and received in PHP.

I placed an

echo $_COOKIE['PHPSESSID'];

at the beginning of the second form (to get the value before validating the form), and I also managed to get $_COOKIE stored in txt file (to get the value when the failure occurs). PHPSESSID values are identical.

 

Was this checking procedure ok ?

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.