Upon debug I'm getting a response that states Lead Capture Page: Not available.
Has anyone run into this problem... I'm passing everything correctly and salesforce.com board is no help at all.
Unfortunately, the error message you got is generic, it doesn't say what the error is.
Using the debug=1 param, or the debugemail param, it tries to return to you the page that the post came from. I think it uses the Referer: header for that. No referrer header (like if you just curl post data to sf), then you get the line above instead of something like
Lead Capture Page: http://yoursite.com/your/form.php
Here's some other tips, given that sf isn't telling you jack:
instead of www.salesforce or test.salesforce, try posting to the same subdomain you see when you log in by browser.
Also look at the return header Is-Processed:, I've seen exceptions in there.
try the generated form; as generated, you change the subdomain as above and it should work as-is. then gradually hack your form and the generated form towards each other till they both fail or both succeed.
Related
I was thinking if their is any way i can check the response header or the page is rendered differently after i have modified the request header or get parameter.
Like:
Original:www.abc.com/index.php?a=2
mODIFIED:www.abc.com/index.php?a=2polo
Now when i have appended the polo string after 2 i should see page rendered differently or it should rendered normally. But how can i check that it was rendered normally or not.
Any way i can compare normal response and the modified "request " response?
Elaboration of my problem.
I have an example.
suppose this is the original url:http://www.lnctgroup.in/institute.php?institute=4
Now this is the modified one on get parameter:http://www.lnctgroup.in/institute.php?institute=4polo
You can see the page rendered normally in original case but while appending "polo" string it shown error as mysql error may be but the page rendered differently.I just want to compare if i am getting the same page or different page after i have modified the get post parameters.
Help
If you would have gone through this then you shouldn't have asked this question.
http://php.net/manual/en/class.httpresponse.php
Go through it first.I cant prepare fully functional code for you here.
So I know the general rule of thumb is after doing a header redirect in PHP, you should call exit() to avoid having extra code running, but I want to know if you put code after the redirect header, if it will always run?
I was doing some research on various ways of tracking referrals in Google Analytics and came across this post: Google Analytics Tips & Tricks – Tracking 301 Redirects in Google Analytics
It recommends doing something like this:
<?
Header( “HTTP/1.1 301 Moved Permanently” );
Header( “Location: http://www.new-url.com” );
?>
<script type=”text/javascript”>
var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(“%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));
</script>
<script type=”text/javascript”>
try {
var pageTracker = _gat._getTracker(“UA-YOURPROFILE-ID”);
pageTracker._trackPageview();
} catch(err) {}</script>
From the way I've always understood the header() function, it's up to the browser and it can run the redirect whenever it wants to. So there's no guarantee the JavaScript would actually begin or finish executing prior to the redirect occurring.
PHP's documentation for the header() function indicates the reason for exiting after a redirect is to "make sure that code below does not get executed when we redirect." That doesn't sound like they guarantee all following code will run, just that it could happen.
Regardless, I found a different way to actually manage the tracking, but I wanted to see if I could find out how exactly header() worked in this situation..
Thanks for your help.
Using the header function in PHP only adds to the headers of the response returned by the server. It does not immediately send any data and does not immediately terminate the connection. Any code after the header call will be executed.
In particular, it's a good idea to add a response body even after doing a 301 redirect so that clients that do not support the redirect also get some descriptive response. Infact according to the HTTP 1.1 specification Section 10.3.2 -
Unless the request method was HEAD, the entity of the response SHOULD
contain a short hypertext note with a hyperlink to the new URI(s). If
the 301 status code is received in response to a request other than
GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
It's a race condition. Once the redirect header is sent to the browser, the browser will close the current connection and open a new one for the redirect URL. Until that original connection is closed and Apache shuts down the script, your code will continue to execute as before.
In theory, if there was a sufficiently fast connection between the client/server, and there was no buffering anywhere in the pipeline, issuing the header would cause the script to be terminated immediately. In reality, it can be anywhere between "now" and "never" for the shutdown to be initiated.
The HTML after your Location line doesn't run inside PHP; it would run in the browser. It's up to the browser whether or not to execute the Javascript that you've included on that page; PHP has nothing to do with it.
To me, the PHP docs imply that any PHP below the header() when you send a redirect will continue to run. But it 'runs' in the PHP interpreter, dumping JS to the browser. There's no relation between what it says in the PHP docs and whether or not the JS gets run by the browser.
EDIT:
Well, as Anupam Jain pointed out, looks like that browsers do not terminate connection without getting the response body and it sounds sensible. So i rethinked my answer
That doesn't sound like they guarantee all following code will run
Exactly More likely it's a warning in case there is some sensible code that shouldn't be executed. A private page contents for example. So, beside sending header you have to also make sure that no sensitive content were sent and exit looks like quite robust solution. So, I'd phrase it as "make sure that sensible code below does not get executed when we redirect."
So there's no guarantee the JavaScript would actually begin or finish executing prior to the redirect occurring.
Exactly It seems it has nothing to do with script execution but rather with browser's will to execute anything after getting 3xx response. I think I'm gonna test it, but you can test it as well too.
I have noticed that the code does still execute and multiple headers based on if statements can cause a "redirect loop error". i made it a habit to now add in die("Redirecting..."); after every header redirect and have not see the problem persist.
It seems like my shared host provider is detecting the presence of "http://www" or "http%3A%2F%2Fwww" in any get request and serving up a 403 page.
I also get an 'in addition' error...
"Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."
This only happens with this string. If I change it to something else the get is successfully submitted and the target page successfully returned.
If it helps I'm writing a QR code getter, so the ability to submit urls is quite important.
Also, strangely I can submit a url as long as it doesn't have 'www' in it. I can also submit 'www' as long as it isn't preceded by 'http://' (or the encoded version)
edit: Just to confirm this wasn't a specific problem with the page I was writing, I went to another page on my website that uses get request and manually inserted the string. This also generates the 403 error.
Yes -- there are two solutions:
Request to remove this strange security feature for your account from your provider.
Don't send urls with http://www in them. For example replace this scting in javascript before sending data to some "%htpwwwashere:(%", that will be replaced by you back in PHP.
Replace any instances of http://www. with StackOverflowRulez and in your PHP have it replace the $_GET StackOverflowRulez with http://www..
My web hosting provider does not permit to use curl FOLLOWLOCATION option so I'm trying to
do it manually by using the header function.
My problem is that I need to keep my PHP script running and to be able to get the redirected URL data for parsing.
How do I do that?
Technically the PHP script continues running after the header () function is called. How you get URL data is another question. Can you not use get_file_contents () or readfile () on the URL?
You read the RAW data the request returns, you check for the redirect header(s), fetch the related URL(s) and do a new get with that URL (dry, rinse, repeat). As simple as that...
Alternatively you could stop being so lazy, check the curl_setopt documentation in the PHP reference manual and find solutions - by reading the comments at the bottom of the page - on how to solve this problem of course.
I'm developing a website, and due to user-input or by other reason, I need to show some error messages.
For this, I have a page named error.php, and I get the error number using $_GET. All error messages are stored in a array.
Example:
header( 'Location: error.php?n=11' );
But I don't want the users to the enter the error code in the URL and see all the other error messages.
For preventing that, I thought I could whitelist the referer page, and only show the error message if the referer is found in my whitelist.
It should be fair similar to this (haven't tested yet ;) )
$accept = false;
$allowedReferer = array (0=>'page1.php', 'page2.php');
if (in_array($_SERVER['HTTP_REFERER'], $allowedReferer )) {$accept = true;}
if ($accept) { $n=$_GET['n'];echo "Error: " . $errorList[$n];}
Is this method good enough to avoid the spy-users?
I'm doing this with PHP5
Thanks
No, it isn't remotely secure: the HTTP Referer header is trivial to spoof, and is not a required header either. I suggest you read this article for an example of exploiting code (written in PHP), or download this add-on for Firefox to do it yourself from the comfort of your own browser.
In addition, your $allowedReferer array should contain full URL's, not just the script name, otherwise the code will also be exploitable from remote referrals, e.g. from
http://www.example.org/page1.php
To summarise: you cannot restrict access to any public network resource without requiring authentication.
Rather than redirect, you could simply display the error "in place" - e.g. something as simple as adapting your present code with something like
if ($error_condition)
{
$_GET['n']=11;
include "/path/to/error.php";
exit;
}
In practice it might be a little more sophisticated, but the idea is the same - the user is presented with an error message without redirecting. Make sure you output some kind of error header, e.g. header("HTTP/1.0 401 Bad Request") to tell the browser that it's not really seeing the requested page.
If you do want to redirect, then you could create a "tamperproof" URL by including a hash of the error number with a salt known only to your code, e.g.
$n=11;
$secret="foobar";
$hash=md5($n.$secret);
$url="http://{$_SERVER['HTTP_HOST']}/error.php?n={$n}&hash={$hash}";
Now your error.php can check whether the supplied hash was correctly created. If it was, then in all likelihood it was created by your code, and not the user.
You shouldn't use an external redirect to get to an error page. How I structure my PHP is like this:
I have a common file that's included in every page, with common functions: handle login/logout, set up constants and the like. Have an error() function there you can pass error information to that will show an error page and exit. An alternative is to use the index.php?include=pagename.php idiom to achieve common functionality but I find this far more flaky and error prone.
If you externally redirect the client (which you obviously need to do sometimes) never rely on the information passed via that mechanism. Like all user input it's inherently untrustworthy and should be sanitized and treated with extreme caution. Don't use cookies either (same problem). Use sessions if you need to persist information between requests.
HTTP_REFERER can be spoofed trivially by those with enough incentives (telnet is the tool of choice there), and shouldn't be trusted.
Error messages should never reveal anything critical anyhow, so I'd suggest you to design your error messages in such a way that they can be showed to anyone.
That, or use random hashes to identify errors (instead of 11, use 98d1ud109j2, etc), that would be stored in a central place in an associative array somewhere:
$errors[A_VERY_FATAL_ERROR] => "308dj10ijd"
Why don’t you just include the error message script? And to get rid of previous output data, use the output control to buffer it and clear it on error:
if ($error) {
ob_clear();
$errorCode = 11;
include 'error.php';
exit;
}
Instead of redirecting to an error page why not include an error page. You can restrict access to a directory containing the php files that contain the error content with .htaccess:
RedirectMatch 404 ^error-pages/*$
and inside the error-pages you can have include-able pages which display errors.
With this method you can be sure that no one can directly access the pages in the error-pages directory yet you can still include them within scripts that are publicly accessible.
If you handle errors before sending headers, you can easily create a function that outputs a basic html page with content, and exit right after it. That way there is no specific need for any other page (apart from the functions page, I guess).
It's as simple as checking if there's a problem, and if there is a problem, just call the function.
I use a function like this that even writes data away when it is called, so I have my own error logs...