I'm on react-router#3.0.0-alpha.2 using the onEnter hook on a route and attempting to redirect the user to an external url (outside of my app). I'd like to do this on the server side. I noticed that the match function callback has a redirect location but that appears to be a route within the app. Is there any way to redirect users to another website entirely?
Since the user is leaving your app, it's not related to react-router.
If you're using express, just call res.redirect() (which defaults to 302) from within the route/middleware that you want to trigger the redirect.
Something like:
app.get('/go-elsewhere', (req, res) => {
res.redirect('http://elsewhere.com');
});
(untested, I hope that's right)
Related
How can I add redirects to my Storyblok project when it is using the Silex Boilerplate?
You can redirect to another page by returning a RedirectResponse response, which you can create by calling the redirect method:
app->get('/{{entry_path}}', function () use ($app) {
return $app->redirect('/{{exit_path}}');
});
http://silex.sensiolabs.org/doc/2.0/usage.html#redirects
When you want to delegate the rendering to another controller, without a round-trip to the browser (as for a redirect), use an internal sub-request (Don't use this if you really want to redirect your page). We provide such an forward in the app.php for the /home slug already, so /home page would be accessible on / without redirecting but doing a subrequest.
I am creating a login application where I need to redirect back to previous url from where the login action was called. I need to know does sails provide a built-in method by using which I can redirect to previous action without creating my own helper function.
You can put this line in your policy if the users fails authentication and requires a login
if(req.method.toLowerCase() === 'get') req.session.afterLoginGoTo = req.originalUrl;
The above line makes sure they are doing a GET request as anything else provides another layer of complexity.
Then after you log the person in you can check for that and re-route
if(req.session.afterLoginGoTo) return res.redirect(req.session.afterLoginGoTo);
else res.redirect('/defaultHomePage');
Just get the origin request from req and then use res.redirect()
I want to create script that's going to be using different sub-domains as user accounts.
The problem i have is, i would like to create script that's going to be redirecting user just before calling log-in attempt, so the session will be saved on sub-domain, not the main domain.
However, I do not want to share the sessions all around, i want to have it, so one user can be logged on his own sub-domain. So setting up
".example.com"
in config file is not way out for me.
EDIT:
Routes:
http://pastebin.com/kgaKJCWx
controller:
http://pastebin.com/73xsejG4
view:
http://pastebin.com/W8eWGrNA
The simplest solution I can think of would be to just use javascript to adjust the subdomain in the form action attribute. Something along the lines of this:
$('form').on('submit', function(){
var username = $(this).find('input[name=username]').val();
var subdomain = username.toLowerCase(); // you might want to do other things here as well
var newAction = $(this).prop('action').replace('yourdomain.com', subdomain + '.yourdomain.com');
$(this).prop('action', newAction);
});
So when the form is submitted, before it actually gets sent the action is updated with a subdomain. You could also use a placeholder in your original action and replace that with the actual subdomain.
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. :)
Several web application authentication protocols (like WS-Federation and the SAML protocol, i.e., so-called 'passive' protocols, and apparently also ASP.NET Forms authentication, see this StackOverflow question, and AppEngine, see this GWT bug comment) lose the original 'URL fragment', i.e. the part after the #-sign.
What happens is roughly the following: in a clean browser (so no cached info/cookies/login information) I open URL (1) http://example.com/myapp/somepage?some=parameter#somewhere. This makes the browser request (2) http://example.com/myapp/somepage?some=parameter, the server redirects me to my identity provider (including URL (2) in the authentication request), and ultimately I'm redirected back to where I came from, which is URL (2): that is the only URL that the server knows about. But I wanted to go to URL (1), and the URL fragment ('anchor') has been lost along the way, actually in the first step already.
This seems to be a fundamental limitation of these protocols, since the server never sees the URL fragment at all.
I know that it according to specifications that the browser requests (2) from the server, when I navigate to (1), leading to this fragment-losing limitation on the SAML protocol, WS-Federation, etc. My question is: how do I work around this limitation?
The obvious workaround is to avoid URL fragments, as suggested in this answer. However, for our specific web application that is not nice, since we use bookmarkable URL fragments in our single-page GWT application, to make sure that a navigation within our application does not cause the page to reload.
My question: What other workarounds or standard patterns are there for this situation?
(I'm specifically interested in a GWT + SAML protocol solution.)
You basically have two options:
avoid using location.hash (use HTML5's pushState instead, at least on browsers that support it; and/or propose a way to generate permalinks within your app – Google Groups does that)
do the redirection using JavaScript. I.e. instead of sending a redirect from the server, send an empty HTML page with some script that takes the full URL (with the hash) and does the redirection using location.assign() or location.replace(). With a bit of luck (depending on the servers), you'll be redirected to that full URL after authentication.
You can of course do both: if the link is a deep-link into the app, then do the redirect (i.e. assume there's no hash), otherwise send a page with JS to make sure you don't lose any state present in the hash.
And finally the obvious third solution, far from ideal: don't do anything, and try to educate users that when they needed to (re)authenticate then they should re-paste the URL or re-click the link or re-click the bookmark.
According to RFC 1738 anchor tags are not sent by the client to the server, when requesting for a resource.
Anchor tags are used to identify a location within a resource and not a different resource on the server. In order to identify the location in the resource, the client needs to fetch the complete resource from the server, and this process need not involve transfer of information about the fragment (as it does not mean anything to the server).
If you do wish to send the fragment character (#) to the server, then you'll need to encode it in the query string, or the client(browser) will simply ignore that section of the URL when it sends the request to the server.
EDIT:
I don't know any real solution but to work around this issue you need to save your full return URL (with anchor tags) somewhere on the client side, because server don't know anything about anchors. For that you could use SessionStorage (http://www.w3schools.com/html/html5_webstorage.asp) to temporary store ReturnUrl until login process is completed. Please note that it won't be supported on older browsers (like <= IE7).
In that case workaround would look something like this:
<script>
if(typeof(sessionStorage) == 'undefined')
{
sessionStorage = {
getItem: function(){},
setItem: function(){}
};
}
window.onload = function ()
{
var key = 'ReturnUrl';
//try to get last returnUrl with anchors
var returnUrl = sessionStorage.getItem(key);
//if we got something, do the navigation
if(returnUrl !== undefined && returnUrl !== document.URL)
{
//clean it up
sessionStorage.setItem(key, null);
//navigate to last URL
window.location = returnUrl;
}
else
{
//store url
sessionStorage.setItem(key, document.URL);
}
}
</script>
PS. Bear with me if there are some syntax errors because I wrote it down from top of my head and didn't try it.