Looking through some legacy code I have in front of me using struts one, I see:
<global-forwards>
...
<forward name="accessDenied" path="/www/jsp/AccessDeniedForm.do" redirect="true" />
</global-forwards>
So it's just a global forward to send to a access denied page.
I am curious about the decision to redirect as opposed to forward. What are the advantages and disadvantages of using it?
What are the pro's and con's of using it?
Before discussing pro's and con's of using that forward element with redirect set to true, let's understand what is actually going on with that configuration. When redirect is set to true in the forward element, a redirect instruction should be issued to the user-agent so that a new request is issued for this forward's resource. This link will probably provide detail information that you need.
The default value for redirect is to false, essentially when the forward element is called, it forward to that path specified and that's it. If you are setting redirect to true, take for example, the browser will make another request. So I think with these said, you probably know or have an idea the pro and con if you really want to use it.
In redirect, the control can be directed to different servers or even another domain name.The redirect takes a round trip.When a redirect is issued , it is sent back to the client , and redirected URL information is in the header instructing the browser to move to the next URL. This will act as a new request and all the request and response data is lost.
In forward , the forwarding is done from server side , the client browser URL do not change.the data is also not lost.It is just like a browser page refresh. Whatever data posted in the first submit is resubmitted again.So use it with caution.
Both forward and redirect are used in different scenarios ,the global forward should be redirect because it is an error situation.
Redirect is slower as it needs a roundtrip.Forwards are faster.
If you specify
redirect="true", Struts uses a client-side redirect
[response.sendRedirect()]
. The JSP will be invoked by a new browser request, and any data stored in the old request will be lost.
Related
From an UI5 application I send a request to a server-side via Fetch API and on the server-side I send a response with a redirect to the UI5-app root directory:
import {constants as httpConstants} from "http2";
res.statusCode = httpConstants.HTTP_STATUS_MOVED_PERMANENTLY;
res.header("Location", "/");
The UI5 application gets the response but browser doesn't redirect an user. The only way to redirect an user to the app root is:
sap.m.URLHelper.redirect("/", false);
Is there any way to force a browser to redirect an user to an UI5-app root without using sap.m.URLHelper? I want to make as hard as possible the prevention of redirection, e.g. with a help of browser's DevTools.
UI5 routing is currently using the # part (called fragment or anchor).
This is client side part of the URL and unknown to the server.
You have maybe luck with some backend technologies and browser, but in general this will not work.
As DevTools can manipulate anyways anything… Make sure backend is secure. UI can always be change by the user, no matter what obscure security measurements you make up.
You can try using the HashChanger to route it back to login page!
Once your validation from server is done, use below code!
jQuery.sap.require("sap.ui.core.routing.HashChanger");
sap.ui.core.routing.HashChanger.getInstance().replaceHash("");
I want to Do a proxy redirect from perl. I have been using Location Header to redirect.
print ("Location: http://www.example.com\n");
The problem with this is the url on the client side changes to a new one (i.e. www.example.com ). I don't want that to happen, so that the end user is unaware of the location we are serving the request from.
If the client is going to do the fetching, it's going to show the URL it's fetching unless the page being fetched is embedded in another page (e.g. by using an iframe). And even then, it's very easy for the user to discover the url if they look.
If instead you do want to a be a proxy (and by all indication you are), which is to say you want to fetch a doc and return it to the client, well, you have to start by fetching the doc you want to return to the client.
Note that you can configure apache to act as a proxy.
Is there a way to go to a url without redirecting to it? Basically I want to call a url from within my application in the background so it can logout a reliant party.
Appreciate the help.
What you are trying to do does not compete us to answer as it's directly related to your own Authentication implementation.
A normal ASP.NET Authentication based in Forms Authentication you will need always to lunch the url from a browser as it is there that relies the Authentication given.
You can give yourself a try by opening your website and log in into it, after that, open other browser brand (not browser window) into your application url... you will see that you also need to login again as the Authentication is hook up into the first browser.
It's Up to you as Application Architect to make this by implementing another way of authentication, normally in this kind'a cases, this happend when consuming web services where you need a authentication code first (given by calling a Login method) and that code is always needed to be appended to the body or header of any call to the system.
This way you can easily remove the authentication code and all procedure calls will fail.
As said, this is not up to us, it's up to you to create the correct Authentication Layer.
from your comment
it's as simple as using WebClient object
WebClient client = new WebClient ();
string reply = client.DownloadString (address);
If you wish to transfer to a new url request you can still use
Server.TransferRequest()
The problem with this is that by not using a redirect the browsers address bar will not reflect the fact that you have moved their request to another URL.
To have the client visit a given URL in the background you should either make an AJAX call to it or possibly have an image with an src of your logout url (though you'd have to make sure that you return a FileResult of your image too). This is how most analytics packages call to their relevant urls in the background.
The problem here though is that neither is 100% reliable, turn off javascript or images on your browser and these results fail.
From what you've said I think what you're after is for a user to continue to any of a variety of pages rather than a specific logout page. If this is indeed the case your best solution is in fact a double redirect.
Have your application redirect to your logout url but before hand put the url of the page you want them to go to into tempdata. Then in the actionresult for the logout page you can do your logging out as required and return a redirect to the url from tempdata.
I understand that most of the languages support server side redirects (asp.net: Response.Redirect, PHP: header( 'newpage' ) ; ). You could also do a redirect with JavaScript (window.location.href="newLocationURL").
When would you choose one over the other ?
With respect to ASP.net/IIS7(app pool in Integrated mode,enable 32 bit apps=false), I noticed that even when the page has a 302 header, the whole page body is sent to the client side.
And I believe this is not the case with PHP, only headers are sent ? To quote
Redirect on client side means following steps:Client-side -> Server-side -> Client-side -> Server-side -> Client-side.
Redirect on Server-Side means:Client-side -> Server-side -> Client-side (headers only)* -> Server-side -> Client-side.
Is there a W3C standard or server side redirect implementation differ from one web server technology to another ?
Edit: I am only concerned about Response.Redirect (in asp.net) and not server.transfer, at least for this discussion
The JavaScript example is actually not a redirect. There's no means of a 301/302 response. It is just a simple request which happens during a certain Javascript event long time after the page is arrived. If you do this during page load, then it would have more overhead than a real redirect and it would not work on JS-disabled browsers as well.
Redirects are to be initiated from the server side with a 301/302 response. All webapp languages/frameworks defaults to 302. You can usually make it 301 by adding one extra parameter or code line which instructs that. The benefit of 301 is by the way that the particular request won't be indexed (anymore) by the searchbots.
In ASP.Net, there is an important distinction between two kinds of server-side redirects. They are Response.Redirect and Server.Transfer.
If you call Response.Redirect, that entails two round trips to the server. On the first call to the server, the server response directs the browser to request the next page. Requesting that next page constitutes the second round trip to the web server.
If you use Server.Transfer, there is only one round trip. Therefore, there is much less network traffic. However, there is a limitation to using Server.Transfer, which is that the target page has to be on the same web server. That is, you can't Server.Transfer from your web app to www.Google.com. But you can Response.Redirect to it.
There are other details involved with using either of these approaches which you would want to research before using them. However, I believe that it is significant in the context of this question to note that in any language, Response.Redirect may result in much heavier network traffic than is really necessary.
It really depends on where you decide that you need to redirect. If it is server side code that determines that you have to redirect, then it is server side code that issues the redirect command. If you can decide client side that a redirect is needed, then do it from the client code.
It is probably more efficient from client side, since you avoid a the back-and-forth of the server side redirect thing..
Why does using Fiddler break my site sometimes on page transitions.
After a server side redirect -- in the http response (as found in Fiddler) I get this:
Object moved
Object moved to here.
The site is an ASP.NET 1.1 / VB.NET 1.1 [sic] site.
Why doesnt Fiddler just go there for me? i dont get it.
I'm fine with this issue when developing but I'm worried that other proxy servers might cause this issue for 'real customers'. Im not even clear exactly what is going on.
That's actually what Response.Redirect does. It sends a 302 - Object moved response to the user-agent. The user-agent then automatically goes to the URL specified in the 302 response. If you need a real server-side redirect without round-tripping to the client, try Server.Transfer.
If you merely constructed the request using the request builder, you're not going to see Fiddler automatically follow the returned redirect.
In contrast, if you are using IE or another browser, it will generally check the redirect header and follow it.
For IE specifically, I believe there's a timing corner case where the browser will fail to follow the redirect in obscure situations. You can often fix this by clicking Tools / Fiddler Options, and enabling both the "Server" and "Client" socket reuse settings.
Thanks user15310, it works with Server.Transfer
Server.Transfer("newpage.aspx", true);
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
Read more here:
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm