I'm trying to redirect the user to another page (default/news) after the login(on default/index) but no matter how much i tried i couldn't get it done. I'm using the login available in the navbar.
I've added this line to db.py
auth.settings.login_next=URL(r=request, c='default', f='news')
Everything in the default controller is the same it includes
def news():
message = "Welcome to News!"
return locals()
I've also tried with this
auth.settings.login_next=URL('news')
Which doesn't work either. Please Help.
Edit:
After searching for days i've found the answer here This is how you do it.
#In layout.html change
<ul id="navbar" class="nav pull-right">{{='auth' in globals() and auth.navbar(mode="dropdown") or ''}}</ul>
# to
<ul id="navbar" class="nav pull-right">{{='auth' in globals() and auth.navbar(mode="dropdown",referrer_actions=None) or ''}}</ul>
And again a change in db.py
#In db.py add these lines:
auth.settings.login_next = URL('news')
That worked for me.
The auth.settings.login_next URL is only a default in case there is no referrer already in the login URL (the referrer is in the "_next" query string variable). The navbar automatically includes a referrer in the auth action links (set to the URL of the current page) -- to override that, you can explicitly specify thereferrer_actions argument and exclude actions for which the referrer should not be set:
{{=auth.navbar(..., referrer_actions=['register', ...])}}
It's now April 2016, and while the original question is still highly relevant, it appears that web2py has changed and the modifications suggested above to layout.html are no longer relevant. There is no reference to "auth.navbar" in the standard layout.html.
The good news is, that all one needs to do is include the python code described above in the default.py controller and it works. Note, I put it in the 'user' function, I'm not sure if that is the best place to put it as most comments just say to put it in 'the controller', without specifying a function.
def user():
auth.settings.login_next = URL('default','dashboard')
return dict(form=auth())
I was able to redirect to a user's home page after login/signup by putting the following code in my product info page.
This way, when they get redirected back to the welcome-product-info page, I check to see if they came from login or signup and direct them to where they should go.
I'd love to find way to use auth.settings.login_next
#
def info():
# If just signed up or just logged in, go to the user's home page and not
# back to this product landing page that referred them
if auth.is_logged_in():
if '/default/user/login?_next=/fnd/home/info' in request.env.http_referer:
redirect( URL( 'user', 'show_campaigns') )
if '/default/user/register?_next=/fnd/home/info' in request.env.http_referer:
redirect( URL( 'user', 'show_campaigns') )
return dict()
Related
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!
I'm working on my first app in PhalconPHP so I'm deep in the documentation while working, but this doesn't seem to be covered.
Let's say that my app is running on www.myapp.tld. In some situations I need to redirect the user back to the home page and for that I'm using the following code:
if ($haveToRedirect) {
$this->response->redirect();
$this->view->disable();
return;
}
Instead if redirecting to www.myapp.tld, the user is redirected to www.myapp.tld/index. I've tried different redirect calls, but all give the same result:
$this->response->redirect('');
$this->response->redirect('/');
$this->response->redirect('/', TRUE);
In the app's bootstrap I've set the BaseUri to be '/':
$di->set('url', function() {
$url = new Phalcon\Mvc\Url();
$url->setBaseUri('/');
return $url;
});
Is there a way to avoid "index" being added and just have it redirect to "www.myapp.tld"?
If a file is not specified, you will be directed to the index page in that directory by default. You need to specify a file location. Also try URI, not URL
The cause of redirection to "/index" was actually in the Permission class I made several weeks ago. It had:
$this->response->redirect('index');
for every controller that guest could not access to. Since I added new controllers I was continuously redirected to index, and noticed that redirect comes from somewhere else when I removed the conditional redirects I've put in the controller.
Anyway, this is it. Lesson learned - next time grep for 'index' before asking for help. :)
I have a page say xyz which contains many sub pages. Some of the subpages are "CUG enabled". In my jsp I am calling currentPage.listChildren() but this is listing the CUG enabled pages only if I login as an admin. If anonymous user hits the url for this jsp then the CUG enabled pages are not listed. Below is my jsp code:
Iterator<Page> itr = currentPage.listChildren();
while(itr.hasNext()) {
Page ctxPage = itr.next();
String url = hostName + ctxPage.getVanityUrl()+".html";
%>
<a href="<%=url%>"><%=url%><br/>
<%
}
}
I also tried logging-in to the workspace as an admin using the method described here, but it didn't work.
Any help is appreciated, Thanks!
I think this behaviour is intented - only users belonging to the user group specified as the CUG can view these pages.
Now it depends for what purpose you need to list those pages.
The easiest solution would be to add the "everyone" to the Admitted Groups in the CUG-Section of those specific page properties. But that's defeating the purpose of having CUG in the first place.
CAUTION: Doing so would allow "everyone" to access those pages - which might not be what you want.
ADDITION:
If you want to preserve access rights you need to go down to node level and access the repository directly.
Here it is shown how you can get a "Resource Resolver with admin rights":
https://cqwemblog.wordpress.com/2013/12/29/ways-to-access-jcr-repository-in-cq5/
You could then use this resource resolver to fetch your page and access it's children.
I'm using Instafeed.js for a client's site:
http://instafeedjs.com/
I've included the script, got my access token & userID. I obtained these by scrolling down to the 'Getting images from your User Account' section of the aforementioned page, and clicking the link at bottom: Don't know your user id or token? Click here to get one.
My code:
$(document).ready(function() {
var userFeed = new Instafeed({
get: 'user',
userId: clientsID,
accessToken: 'MY_ACCESS_TOKEN',
template: '<img src="{{image}}" />',
target: 'instafeed',
limit: 6
});
userFeed.run();
});
I've created an empty div with the 'instafeed' id. The div is being populated with 6 empty a tags, each with an empty image tag. I don't have any console errors.
In the instructions on this site, I'm told to
"make sure your token is set to basic authorization, which only allows
GET requests. If you aren't sure what scope your token has, check
under your account page."
On my account page, I have an 'Instafeed.js' application set up, but the only option I have is to revoke access. I cannot edit or see any other options, so I'm not sure if this could be related to the problem.
Any help would be greatly appreciated!
All tokens issues by the API are given the basic scope, unless the scope was specified in the authentication request.
From the Instagram API Docs:
Currently, all apps have basic read access by default. If all you want to do is access data then you do not need to specify a scope (the “basic” scope will be granted automatically).
You can verify which scope the token has by visiting the Manage Applications page. Each application will display what kind of access level it has. A basic permission set should say something like "Access your basic information":
So you shouldn't need to do anything to set the token's permissions, that's all handled when the token is created. If you used the helper link on instafeedjs.com to get that token, then all the permission levels should already be taken care of for you.
In case someone else runs into this issue, my problem was actually a conflict with Shopify's template engine. When I removed the template option everything worked fine, thanks to Steven here who actually responded to my email! This dude is killer.
In Shopify, if you drop the configuration script into a new "asset" labeled instafeed_config.js and then call it with
{{ "instafeed_config.js" | asset_url | script_tag }}
after loading
{{ "instafeed.min.js" | asset_url | script_tag }}
then you are able to use the Template feature.
You can adjust the template section.
Change the following:
img src="{{image}}"
To:
img src="http:{{image}}"
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).