OK, thank you for clarifying.
1. The initial question was "If a CRED form redirects a logged in User (on form submission) to a page that uses a Custom Page Template in my theme which executes code, should the URL be nonced?"
The answer is no, I would not know why you would want to wp_nonce_url this Form Success Redirect.
Of course, if you pass some Query args when you submit that form and on the targe page you have custom code listening to those args and that can, in fact, execute something, it is up to you to make sure, the URL param requests are sanitized, controlled and safe.
They should be if your custom code is. The receiver (your custom code) should make sure the parameters passed, if any, can only do something if (for example) the user submitting them is logged in, or has specific rights, and that stuff gets sanitized, if there is potential to pass some malicious code to the URL for example, and this (thru your code) would somehow talk to the database.
But all of this would be the precise same question to resolve with or without Toolset Forms.
It will solely depend on what your code does, and what you expect to be passed to it how. But it does not depend on toolset forms, as you could perfectly fine pass URL arguments to that code sitting on your success page by any other URL directing to that page.
Only if it is a success message, the target is created as well by Forms, and then, you cannot add any custom code anyway, because that success message is not a page or template that executes code.
Again if you here somehow manage to have code in any of the success targets or even the post created, that listens to some (custom) URL params, then it is not depending on Toolset Forms to validate and make that code safe.
This is what Shane means with "This would be custom code". We could not help with this as not related to Toolset Forms, generally.
Yes, forms is used to bring the information, but that is not the issue since the information can be brought to your code by any means possible.
2. The post id (that the form edits) needs to be passed as a URL parameter to be used in the Custom Page Template.
OK, you can do that, you just add any URL parameter in the redirect snippet, for example.
For example:
https://toolset.com/documentation/programmer-reference/cred-api/#cred_success_redirect
add_filter('cred_success_redirect', 'custom_redirect',10,3);
function custom_redirect($url, $post_id, $form_data)
{
$url = '<em><u>lien caché</u></em>'.$post_id;
return $url;
}
What the code that sits on the target does with the value of url_param, is up to you as the Webmaster who creates that code, Toolset Forms cannot help validating that code or it's input. This needs to be done in the target code, logically.
If you like to pass a nonce to the URL you can do so, but it is not Forms generating or handling this, it is WordPress and your custom code that must match the nonce.
3. Some of the code shared in the examples here https://toolset.com/forums/topic/cred-redirects/#post-1513229 is faulty and throws fatal errors, due to a wrong syntax (at least in example B), and example C to do just what you want, I see however it Encodes the "&" sign
B, if corrected, will give you ?nonce_token=f02614c307&cred_referrer_form_id=20
C, if used, will give you ?choice=27&nonce_token=f02614c307&cred_referrer_form_id=20
I am not sure what "not working" refers to in this case, if you mean the encoded & (&), this should not be an issue, because the URL parameter is still produced fine:
The nonce_token is added fine, as seen in the URL
You still should be able to read it from that URL in your custom code.
This is, in any case, an issue of wp_nonce, see here:
https://developer.wordpress.org/reference/functions/wp_nonce_url/
> Note that wp_nonce_url escapes & to & and may cause links or redirects to become incorrect.
What is the precise problem with the custom code in related to Toolset? It seems to me it works just as expected.
If not, please can you specify what "does not work" means in this case?
4. So, are you saying the cred redirect url doesn't need to be nonced in my scenario?
As mentioned - we cannot answer this consistently for all cases.
It fully depends on what your custom code does and how unsafe it can be if unexpected input is added to the URL as params
The Forms will not be able to be responsible for this, and it is correct that if you need to make sure only specific referrers can add specific URL params, you need to use Custom Code, to validate this.
5. And if so, what is the difference between using the cred_form_action_uri_querystring_array filter and my example Code A (https://toolset.com/forums/topic/cred-redirects/#post-1513229)?
Your code fires on success redirect, the cred_form_action_uri_querystring_array fires when the form is loaded but also when it is submitted, and it doesn't let you change the URL but the URL parameters.
I see no problems with the code version C in your example, please can you elaborate what the precise issue is that you face with that code as due to Toolset?
Meaning, it would "not happen" if not using Toolset? The URL Encoding is not due to Toolset, you can see the precise same results if inserting this to any page or another type of form not using Toolset at all
Thanks for your patience!
