We would like to keep the ideas we have previously presented to (non logged in) clients, but which are no longer "current". We set them to being private WP posts, so that they are no longer available to non logged in users. However, we would like to redirect anyone who clicks on that original link to a page which shows all of the currently active ideas instead.
Research led me to the solution below, but in our case we need to redirect to a specific url in each case. Our theme (the amazing Total theme from WP Explorer/AJ) does have a field for the redirect url to be entered at post level, but actually the value of the url is determined by the value of a custom taxonomy on a post ie all posts with that Taxonomy should redirect to the same url in all cases.
add_action('template_redirect', 'your_theme_private_posts_redirect', 99);
function your_theme_private_posts_redirect()
{
if (is_single() && 'private' == get_post_status(get_the_ID())) {
wp_safe_redirect(home_url());
exit();
}
}
Credit https://stackoverflow.com/questions/68954429/wordpress-how-to-redirect-private-custom-post-types
I understand that the above code would redirect all private posts to the home url, but how can I adapt it to do the following:
a) Only to apply to non logged in users and b)to set the url to be the value held in the redirect field on the post OR (better still) a custom field on the agency_artist custom taxonomy for that post. Hoping someone can help!
Related
We have a Drupal 7 webform that redirects to a url upon successful submission.
What we need to do is redirect the user if they land on the same webform again and have already submitted.
Do we need a module for this, or do it programmatically?
Thanks in advance.
I looked through the webform module and didn't find any setting that will redirect the user if the user has already submitted a form, so I think you need to do it programmatically.
Note: It might be possible without a custom module by using the rules module. I haven't tried this.
To do it programmatically you could do something like below. It implements the hook_node_view() and checks if the user has already submitted anything by using the webform api function webform_get_submission_count(). (edit: the custom module in this example is called example_webform)
<?php
/**
* Implements hook_node_view().
*/
function example_webform_node_view($node, $view_mode, $langcode) {
global $user;
module_load_include('inc', 'webform', 'includes/webform.submissions');
$submission_count = webform_get_submission_count($node->nid, $user->uid);
if (!empty($submission_count) && $submission_count > 0) {
$redirect = $node->webform['redirect_url'];
drupal_goto($redirect);
}
}
As it is now it will reuse the page that is used when the form is submitted, so if you choose to do this remember to make the success page reflect this. (E.g. it would be strange for the success page to say "your post has been saved" if the user lands on it for the second time.) Or you could replace the $redirect with another page than the one from the webform setting.
Also note that the webform will still add the message "You have already submitted this form. View your previous submissions." if this is enabled.
So here is the solution that we ended up going with.
I saved the webform and made it available as a block
I created a page to hold the webform
I configured the block to appear above the page content
In the page content I put in some javascript to detect if the form element was present - if not forward to the correct url
So the webform redirects correctly upon submission(set in the webform settings), and it then redirects if the user lands back on that page and has completed the webform.
This question already has answers here:
Prevent user from seeing previously visited secured page after logout
(7 answers)
Closed 6 years ago.
I have a JSP page with a form where you fill up certain details. On submitting the form i call a servlet which then updates details in a database after that i redirect to a page i display a confirmation message to the user.
The problem i have here is when the user clicks back he goes to the form page again where if he clicks a submit button, it creates a new record in the database.
Consider this similar to a shopping cart example where in this case he would buy the same item twice. But the only problem here is i cannot handle this in backend, i.e. the database can never know a redundant operation is taking place.
I need to handle this from the client side.Bit weird but i have to do it this way.
Basically when the user clicks the back button i don't want him to be able to go to the form page and may be just to some other page.
This is a typical HTML form issue, you can solve it through any one of following methods
1) Server side (page expiration): Since you've mentioned that the page refreshes and goes to the confirmation. You can set no-cache and add a page expiration time as -1 to the page you have that form.
So that when user presses the back button, he will see that the page has expired. He will be forced to load the page freshly. This is the behavior that I see in most banking websites.
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
2) Using turn Key method: When the form loads, you can generate a random key in session memory and also embed it as a hidden value in the page.
During form submission, check the submitted hidden key against the value in session. If exists, then add the entry to database otherwise you can reload the page with a fresh key for the user (who might have done that unintentionally).
In load balanced or web farms, consider persisting the turn key in Database against the current user.
3) Client Side (Not recommended) : You can restrict the user from using the browser back button by removing the page from the history. (One side effect is that it will remove the entire history for that browser tab/window)
history.pushState(null, null, document.title);
window.addEventListener('popstate', function () {
history.pushState(null, null, document.title);
});
If you need the same support for older browsers where push and pop states are not supported, you can use following snippet.
<script>
function preventBack() {
window.history.forward();
}
setTimeout("preventBack()", 0);
window.onunload = function() {
null
};
</script>
Before redirecting to the JSP page send these headers with the response from the controller so that the page is not stored in cache and the browser will always request a new page from the server.
response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0);
So every time you go back to that page a new page will be requested from the server and will be displayed with the cleared input fields.
You could implement a PRG-Pattern (https://en.wikipedia.org/wiki/Post/Redirect/Get) using php.
Basically, after successfully submitting the form you redirect to a confirmation page which informs the user that their submission was successful/accepted/etc. and also set a variable which you can later use to check if said submission has been submitted yet.
When the user tries to reload said page or go back you can check the variable and display either the form again or the confirmation page based on if the submission has been submitted already.
I think following flow is the best:
Client submits data to server
Servlet processes it
It returns HTTP 303 redirect to client
Client redirects to success page
After this flow, refresh, back button will work properly.
For more information read Simple Post-Redirect-Get code example
I am authotizing my app in the following way:
// authorize app!
$('#authApp').click(function(){
var oauth_url = 'https://www.facebook.com/dialog/oauth/';
oauth_url += '?client_id=#{app.id}';
oauth_url += '&redirect_uri=' + encodeURIComponent('https://www.facebook.com/pages/null/#{fbPageId()}/?sk=app_#{app.id}');
oauth_url += '&scope=user_likes,user_photos';
oauth_url += '&app_data=7B%27game%27%3A+%27key%27%7D';
oauth_url += '&state=sbSbsbSb';
As you can see I am setting the 'state' param as part of the query string.
Now when the user authorizes the app he is redirected to the redirect url.
However the data passed in the state parameter is not posted to my app nor is it part of my app's iframe query string. I was expecting to find it as part of the signed request, but no. This is the deserialized signed request posted back after authorisation
{ algorithm: 'HMAC-SHA256',
expires: 1348927200,
issued_at: 1348921162,
oauth_token: 'AAA...',
page: { id: '490...', liked: true, admin: false },
user: { country: 'ec', locale: 'en_US', age: { min: 21 } },
user_id: '1...' }
I do see that the state is included of the parent page's query string. I need to access that parameter from my app (running inside an iframe). I believe that I cannot just access the parent page's window location because of same origin policy restrictions.
I have read through the documentation and searched online. Persisting data across an app authotization needs to be done using the state parameter. However it is nowhere stated how to retrieve that state param once redirected back to your app.
This is from the facebook doc's regarding the state param:
A unique string used to maintain application state between the request
and callback. When Facebook redirects the user back to your
redirect_uri, this parameter's value will be included in the response.
You should use this to protect against Cross-Site Request Forgery.
Am I supposed to get the state data back from the parent's page query string?
Or am I doing something wrong?
* EDIT *
I am storing the user to user request Id in the state parameter. For example A invites B to participate in the app via a facebook request. Once B authorises the app A needs to be rewarded. So I need to know that B came to the app following A's invitation. Therefore I store the requestId in the state param, so once B has authorised the app I can take appropriate action.
* EDIT 2 (SOLUTION) **
If your redirect_uri is pointing to the Page Tab URL then facebook will NOT send back the state parameter! It will only be sent back if you redirect to the Canvas URL !!!!!
The Facebook documentation you referenced is a bit confusing. The only thing you should be doing with the state parameter is making sure you are not a victim of CSRF. Facebook's server side authentication flow gives an example of this in PHP. In short, you should be storing the state value in the session and then verifying that the session value is the same as what Facebook passes back to you in the request. The key line in their PHP example is:
if($_SESSION['state'] && ($_SESSION['state'] === $_REQUEST['state'])) {
// Continue with application logic here because state matches.
// Otherwise, exit immediately because you're a victim of CSRF!
So back to your problem. From your redirect URL and the response you are getting, it's obvious your app is on a Facebook Page Tab. See the authentication flow for page tabs for how you should be doing this. Note they are not using the state parameter in step 2 and that the state parameter is never mentioned in page tab authentication flow. So even if you wanted to use the state parameter for something other than its intended use, you are out of luck.
Based on your edits, I suggest you check out the documentation on requests. Note that the user clicking on the request will be redirected to your canvas app, not the page tab. "The canvas URL will also contain an additional GET parameter request_ids, which is a comma delimited list delimited list of Request IDs that a user is trying to act upon." So there is no need for you to be trying to do this yourself.
Am I supposed to get the state data back from the parent's page query string?
No, not when authenticating within a canvas/page tab app. The only query string parameter that gets passed to your app in this scenario is the content of the app_data parameter.
But you don’t need the state parameter in this scenario – verifying the signed_request is absolutely sufficient, because it’s signed with your app secret, that only you and Facebook know. So that is enough protection against “manipulated” requests right there already.
See https://developers.facebook.com/docs/authentication/canvas/ resp. https://developers.facebook.com/docs/authentication/pagetab/ for more details. (And see how they do not mention the state parameter at all.)
Edit:
I am storing the user to user request Id in the state parameter. For example A invites B to participate in the app via a facebook request. Once B authorises the app A needs to be rewarded. So I need to know that B came to the app following A's invitation. Therefore I store the requestId in the state param, so once B has authorised the app I can take appropriate action.
That’s a misuse of the state parameter … it’s supposed to achieve something completely different (CSRF protection, as the docs say).
While this might work in your scenario – why are you not using the app_data parameter to transmit this piece of information? That’s the designated way of transferring info to canvas/page tab apps.
I have a link pointing to restricted page. When I access the link directly in logout status, its redirect to 404. Actually it should redirect to login form.
I tried:
config {
typolinkLinkAccessRestrictedPages=PAGE_ID
typolinkLinkAccessRestrictedPages_addParams = &return_url=###RETURN_URL###&pageId=###PAGE_ID###
}
Not working.
Also I tried the login status redirect plugin, no use.
Anyone know how to do this? I am using TYPO3 version 4.4.8.
As this is still unanswered, does this help?
Valid for TYPO3 < 8.x
# Check if user is logged in:
[usergroup = *]
# do something
[else]
page.config >
page.config.additionalHeaders = Location: http://www.yourdomain.org/login.html
[end]
I recently posted this to another questions and it crossed my mind that it might be a suitable workaround for your probem.
Found here
I'm not sure how to make redirection work correctly, but perhaps a bit of background will be helpful.
typolinkLinkAccessRestrictedPages only interacts with link generation. That way, anywhere you have a link to an access restricted page, you should get a link that points to the "PAGE Id" page. I suspect you are using your login pid in place of PAGE Id, which I guess should work, but I haven't used this particular feature. I have typolinkLinkAccessRestrictedPages = NONE which makes all links show up, linked to the correct url, but only users who are logged in will successfully load those pages.
If anyone, without being logged in, uses a bookmark to an access restricted page, or they click on one of these links, or directly type in the address, or whatever, they will run into TYPO3's 404 handling (with the error message: ID was not an accessible page). To change how TYPO3 handles these errors, you need to change what TYPO3 does via this setting in localconf.php:
$TYPO3_CONF_VARS["FE"]["pageNotFound_handling"]
I don't know if there's a clean way to just automatically redirect to the login page without hacking the pageNotFound_handling.
As far as the typoscript solution, that wouldn't work for my site, because the trigger isn't whether or not someone is logged in (often they will not be logged in)--the trigger for my site is trying to access a protected page when you are not logged in. I don't want it to redirect everyone who isn't logged in because a lot of pages don't require any login.
Fe_login cannot alone do this...
Follow these steps::
Install "pagenotfoundhandling" extention after felogin login
configuration.
Configure 403 page as login page in "pagenotfoundhandling" extention configuration.
Then, when you try to access "Access restricted page", "pagenotfoundhandling" will redirect to login page then pagenotfoundhandling handle redirect to again requested page. I have tested this on TYPO3 6.2.14
And I found an other workaround that looks like it should work fine.
# pages and subpages starting at 123 and 321 are restricted
[PIDinRootline = 123,321] && [loginUser = ]
page.headerData.666 = TEXT
page.headerData.666 {
data = getIndpEnv:TYPO3_REQUEST_URL
wrap = <meta http-equiv="refresh" content="0; URL=/passwort/?referer= | " />
}
[global]
Important notice: Do not restrict the complete page, only all contents of the page. Otherwise RealURL will trigger the 404 handler.
At the moment page.config.additionalHeaders (like used by #Mateng) does not support stdWrap, though you cannot add a referrer to redirect to the desired page after login (see TYPO3 Forge and vote for feature request).
Complete solution :
1. first in typo3conf/LocalConfiguration.php you have to add:
'FE' => [
'pageNotFound_handling' => 'REDIRECT:/login/',
"pageNotFound_handling_statheader" => 'HTTP/1.1 404 Not Found',
...
],
then add to typoscript :
'
config {
typolinkLinkAccessRestrictedPages = YOUR_LOGIN_PAGE_ID
typolinkLinkAccessRestrictedPages_addParams = &return_url=###RETURN_URL###
}
plugin.tx_felogin_pi1.redirectMode = referer
'
Because there seems no proper solution for this behaviour of TYPO3, I use the following workaround with RealURL.
Create a 404 page in TYPO3
set the Speaking URL path segment to "404-error" and check
Override the whole page path
Add a text that describes what is happening (i. e. "Page doesn't exist or is restricted, please login")
Add the felogin plugin to that page and hide it when users are logged in
Set [FE][pageNotFound_handling] = /404-error/ in the install tool
This 404-error page is shown every time a user requests a page that he is either not allowed to see or a page that does not exist. When the user uses the login form on the page, he will find the proper content immediately after login because the URI did not change at all (when there is no redirect configured for the fe_login plugin).
Problem:
I have a webforms app where every page inherits from BasePage.cs
I also have another class AuthenticatedBasePage.cs which inherits from BasePage.cs
BasePage.cs has some code which finds out if a Forms Authentication cookie is set, and if so, sets a IsAuthenticated boolean flag and a MyAppUser object (only has properties such as name, age, gendery) which means every page on the site can see if the user viewing the page is logged in or not, and if so, read the values of MyAppUser.
AuthenticatedBasePage has an additional feature where if anyone tries to browse to a page inheriting from this class are not authenticated, they are redirected to the login page with a 'returnurl' querystring variable set.
I would to have a similar setup in my MVC2 app. I've done a fair bit of reading that says I shouldn't reference HttpContext in my BaseController.cs (which all my controllers inherit from) as that means I can't unit test it. My first question is, how can I make the IsAuthenticated and MyAppUser objects available to every page? Secondly, how do I create pages which only authenticated users can access, and if they are not authenticated, they get redirected to the login page with the returnurl querystring variable set?
Many thanks,
A.
P.S. I'm not using the MembershipSchema, I'm only using the FormsAuthentication.SetCookie method.
What you want is the Authorize attribute. This article has a great explanation of how to use it with forms authentication.