Pass URL parameters PAST the Login page

[BrianNardone]

I am sending a link in an email to associates that will take them to a page with a Restrict Access SB on it. The Restrict Access server behavior redirects them to the login page; that works fine. The login page also functions perfectly well.

But, the link in the email has two URL parameters on it, the purpose of which is so that when the associate gets to the destination page after logging in, those parameters will filter the recordset and extract the information specific to the individual and their contract.

Problem: the URL parameters seem to get TO the page with the Restrict Access SB on it (because they show up in the URL) and they also show up in the URL of the Login.php page. But when I actually hit ‘submit’ and log in, they don’t carry past that point to the destination page, thus no information from the data table shows up in the contract. I have tried every conceivable combination of record sets and GET’s and whatnot and I cannot get this seemingly simple problem solved.

Is there something unique in the Login or Restrict Access SB’s that strips the URL of the parameters?
If so, how do I overcome that?

If that can’t be overcome, how do I use the Session variables created by the Login transaction to extract the information from the data table?

[David_Powers · Accepted solution]

Interesting question. I have studied the code in the Restrict Access to Page and think that's where the problem lies. What puzzles me is that you say the variables are preserved in the query string. They're not. The only thing that's in the query string is the page to which the user is to be redirected after logging in. Fortunately, the fix is simple.

Locate the following section in the Restrict Access to Page code:

if (!((isset($_SESSION['MM_Username'])) && (isAuthorized("",$MM_authorizedUsers, $_SESSION['MM_Username'], $_SESSION['MM_UserGroup'])))) {   
  $MM_qsChar = "?";
  $MM_referrer = $_SERVER['PHP_SELF'];
  if (strpos($MM_restrictGoTo, "?")) $MM_qsChar = "&";
  if (isset($QUERY_STRING) && strlen($QUERY_STRING) > 0) 
  $MM_referrer .= "?" . $QUERY_STRING;
  $MM_restrictGoTo = $MM_restrictGoTo. $MM_qsChar . "accesscheck=" . urlencode($MM_referrer);
  header("Location: ". $MM_restrictGoTo); 
  exit;
}

Change all instances of $QUERY_STRING to $_SERVER['QUERY_STRING'] like this:

if (!((isset($_SESSION['MM_Username'])) && (isAuthorized("",$MM_authorizedUsers, $_SESSION['MM_Username'], $_SESSION['MM_UserGroup'])))) {   
  $MM_qsChar = "?";
  $MM_referrer = $_SERVER['PHP_SELF'];
  if (strpos($MM_restrictGoTo, "?")) $MM_qsChar = "&";
  if (isset($_SERVER['QUERY_STRING']) && strlen($_SERVER['QUERY_STRING']) > 0) 
  $MM_referrer .= "?" . $_SERVER['QUERY_STRING'];
  $MM_restrictGoTo = $MM_restrictGoTo. $MM_qsChar . "accesscheck=" . urlencode($MM_referrer);
  header("Location: ". $MM_restrictGoTo); 
  exit;
}

The query string should now be preserved intact when the user is redirected to the original page.

I'll report this problem to Adobe.

By the way, you can use Find and Replace to change all instances of $QUERY_STRING to $_SERVER['QUERY_STRING']. If you're feeling ambitious, though, you can fix this problem by editing the configuration file that builds the code for the Restrict Access to Page. In CS4 on Windows, the file you need to edit is C:\Program Files\Adobe\Adobe Dreamweaver CS4\configuration\ServerBehaviors\PHP_MySQL\RestrictAccess_main.edml. It will be in a similar location in the Applications folder in a Mac. Just change all instances of $QUERY_STRING to $_SERVER['QUERY_STRING'].

[BrianNardone]

Do you remember how Charles M. Schultz would draw Snoopy when he was

dancing; nose high in the air, little more than a smile and happy feet? That’s

how I felt when I realized that THE David Powers, the author of my FAV code

book of all time had answered my question. It is the most coffee-stained

book that I own; you can extrapolate all good things from that.

As to the reason I said that the “variables are preserved in the query

string”, they only appeared after I messed around with the code and changed

the

“$MM_restrictGoTo = "../Farsi_URA/Login_Translator.php";”

to:

$MM_restrictGoTo = "../Farsi_URA/Login_Translator.php?Film_ID=&FilmTitle=";

etc

(I used various means to get them in there, including <?php echo $_GET…

?> and others too so I can’t remember which of them worked the

best.

I also tried to do this with the code written by the tick box for “go to

Previous URL if it exists” but that simply eliminated all reference to any

URL params.

Believe me, it took some messing around to do it, but they showed up in

Login page URL so they must have been sent there by the original destination

page with the Restrict Access SB.

Funny thing though, though I could get the ?Film_ID= and FilmTitle= to

show up in the URL, they would show up looking like this:

?Film_ID={GET.Film_ID}&FilmTitle={GET.FilmTitle}

or

?Film_ID={$row_rsTransAgreement['Film_ID'])&FilmTitle={$row_rsTransAgreement['FilmTitle'])…

rather than ?Film_ID=2&FilmTitle=Molly’s Dog. Despite hours of rearranging

things, nothing worked.

Odd.

Your recommendation worked perfectly except for… ( I’m sure you’ve already

spotted my next question: )

Where do I add the stripslashes to remove the apostrophe in Molly’s? When

I remove it manually in the URL, the record set filters perfectly; with it

in there nothing appears.

and thank you David!

Brian

[David_Powers]

Do you remember how Charles M. Schultz would draw Snoopy when he was

dancing; nose high in the air, little more than a smile and happy feet?

Yes, I used to have a Snoopy sweatshirt with that on the front. On the back, it said, "I must start acting more sensibly... tomorrow".

Where  do I add the stripslashes to remove the apostrophe in Molly’s?   When

I remove it manually in the URL, the record set filters perfectly; with it

in there nothing appears.

Don't understand. You don't use stripslashes() to remove apostrophes. You use it to remove backslashes inserted if magic quotes are switched on. Not only that, but Dreamweaver's GetSQLValueString() function handles all that for you automatically (assuming you're using DW 8.0.2 or later).

I have been using a simple test setup to check everything. In the protected page, I have the following conditional statement:

<?php 
if (isset($_GET['film'])) {
     echo $_GET['film'];
}
?>

When I try to access that page without logging in, using the following URL success_redirect.php?film=Molly's, I'm sent to the login page. After logging in, that conditional statement displays the following if magic quotes are ON:

Molly\'s

If magic quotes are off, it displays

Molly's

You shouldn't need to remove the apostrophe for a database search. The GetSQLValueString() function removes the backslash if magic quotes are on, and then wraps the value in mysql_real_escape_string() to make sure it's escaped properly for the database.

[BrianNardone]

>>Don't understand. You don't use stripslashes() to remove apostrophes. You use it to remove backslashes inserted if magic quotes are switched on.

**Yes, I mis-spoke; I meant the backslash

>>Not only that, but Dreamweaver's GetSQLValueString() function handles all that for you automatically (assuming you're using DW 8.0.2 or later).

**I’m using CS3

>>I have been using a simple test setup to check everything. In the protected page, I have the following conditional statement:

<?php

if (isset($_GET['film'])) {

echo $_GET['film'];

}

?>

• That all makes sense and checks out on my side as well. The comparable code inserted by CS3 was:

$colname_rsTransAgreement = "-1";

if (isset($_GET['Film_ID'])) {

$colname_rsTransAgreement = $_GET['Film_ID'];

}

$colname2_rsTransAgreement = "-1";

if (isset($_GET['FilmTitle'])) {

$colname2_rsTransAgreement = $_GET['FilmTitle'];

}

1) Magic_quotes_gpc is ON. I suppose I could ask my host to turn it off but since I’ve written about 80 pages with this configuration, I’m nervous about changing it now. Would that mess up the other pages?

>>The GetSQLValueString() function removes the backslash if magic quotes are on, and then wraps the value in mysql_real_escape_string() to make sure it's escaped properly for the database.

**That makes sense too, so I’m wondering why it isn’t removing it the way it should. Is it possible for code to be out of ‘position’?

When I am not yet logged in and I click the link in the email to the Agreement page, it sends me to the Login page:

http://www.cinelingua.com/CommandControl/Farsi_URA/Login_Translator.php?accesscheck=%2FCommandControl%2FFarsi_RA%2FTranslator_Agreement.php%3FFilm_ID%3D2%26FilmTitle%3DMolly%27s%2520Dog

So far, so good. That seems to tell me that the Agreement page is okay and that the issue is with that which happens on the login page. (You can login with username: David password: Powers )

But there are two different outcomes:

When I first login, it goes to the page this way:

http://www.cinelingua.com/CommandControl/Farsi_RA/Translator_Agreement.php?Film_ID=2&FilmTitle=Molly\'s%20Dog WITH the backslash even though page has the GetSQLValueString() real_escape

But, in testing, I found that if I click the email link when I am already logged in, it naturally bypasses the Login and goes directly to the Agreement page and the backslash is gone, so the issue must be on the Login page. Right? But where?

David, would you have time to look at the page code for these?

[David_Powers]

Those links just send me here: http://www.cinelingua.com/index_temp1024.htm.

[BrianNardone]

Yup, forgot to remove the .htaccess. Please try it again. Thanks

[David_Powers]

Sorry, I don't see any difference between those pages. I'm not sure what I'm meant to be looking for.

[BrianNardone]

Hi David,

I thought you were back to work.

The remaining issue is that the recordset information that should appear in the Translators Agreement page doesn't appear due to the three backslashes that appear in the URL Translator agreement page. I suppose it makes sense that the Restrict Access php code would insert a backslash when it encounters an apostrophe or quote while sending the visitor back to the Login page, but I just don't know how to escape out of that. And where the other two backslashes come from is beyond me. In my other film titles that don't have apostrophes, it works just as you laid it out.

I noticed that when the Restrict Access page sends the user to the Login page, in the URL there is a %5C, which is the designation for \ ... so eliminating that is the key.

Anyway, if you click the link above and login with username: David - password: Powers it will give you the three back slashes. Maybe you can figure out where they come from. I sure can't.

Thanks for your help.

Brian

[David_Powers]

It looks as though magic quotes are inserting a backslash in the query string. Try this in the amended Restrict Access to Page server behavior. Change this line:

$MM_referrer .= "?" . $_SERVER['QUERY_STRING'];

to this:

$MM_referrer .= "?" . stripslashes($_SERVER['QUERY_STRING']);

Now you know why magic quotes are being removed from PHP 6. They were meant to help inexperienced programmers, but became a massive headach for experienced and inexperienced alike.

[BrianNardone]

Well, thanks that got rid of two of the three slashes. I just have to figure

out where to strip the other one.

[BrianNardone]

Okay, so I found where to put the strip slashes to remove the third slash -

it's in the Login page itself.

//declare two session variables and assign them

$_SESSION['MM_Username'] = $loginUsername;

$_SESSION['MM_UserGroup'] = $loginStrGroup;

if (isset($_SESSION['PrevUrl']) && true) {

$MM_redirectLoginSuccess = stripslashes($_SESSION['PrevUrl']);

}

header("Location: " . $MM_redirectLoginSuccess );

}

else {

header("Location: ". $MM_redirectLoginFailed );

Now I must figure out why it is letting me log in to a record when using the

wrong username and password. That's weird too.

Thanks for your help on the first steps. I would have never found that on my

own.

Brian