I'm setting url with query string when anyone hit such page which is only access after login. I set that controller name as query string and redirect to login page. everything working good till here. but when i login and using Response.Redirect(returnUrl); than it is converting my session null. here returnurl is coming as /Control/Index. if i simply redirect as return RedirectToAction("Index", "Control"); than it is working fine.
What can be the problem.
Working Good Redirection - RedirectToAction("Index", "Control");
Not Working Redirection - Response.Redirect("/Control/Index");
Your problem comes down to a question:
What is the difference between Response.Redirect() and RedirectToAction()?
Both are used to transfer request from one page to another. Both will give 302 status code. Both can be used for the same purpose, but the devil's in the details.
Response.Redirect (as well as Redirect() used with just URL) redirects a request to a new URL and specifies the new URL. RedirectToAction() terminates execution of the current request and starts execution of a new one using specified action and/or controller name.
RedirectToAction() keeps the old request with session. Response.Redirect() does not as it's out its scope. RedirectToAction() stays on the server to execute another request, while Response.Redirect() returns the response and then processes next request from scratch as a separate one.
So, is RedirectToAction() better? It's not better, it's just meant for different use case. For example, you can't redirect to different website with RedirectToAction() as it's out of scope of your local web application. You'd have to use Response.Redirect() while passing the URL to the desired webiste.
See this article explaining the differance in greater detail and illustrating round trips made for both methods. Notice that it does not exactly explain your problem as it shows difference between Response.Redirect() and Server.Transfer() from ASP.NET Web Pages, but the presented concepts taking place are very similar.
Related
I'm trying to a CSRF protection to an existing MVC4 web application which uses DevExpress grids. I've added the Html.AntiForgeryToken() into the forms on the aspx pages (which contain ascx as partials containing the grids) and can see the __RequestVerificationToken and it's value clearly in developer tools when a save is called.
I've tried commenting out all my ValidateAntiForgeryToken attributes bar one - I went with the delete post method for simplicity (And also to eliminate the DevExpress grids messing with it) and I still keep coming up against this error:
There was a HttpAntiForgeryException
Url: http://localhost:54653/Users/Delete/f86ad393-0039-44e8-beed-a66dbab9266e?ReturnURL=http%3A%2F%2Flocalhost%3A54653%2FUsers
The exception message is
The required anti-forgery form field "__RequestVerificationToken" is not present.
Does anyone have any idea why this might be happening? Could it be that the error is non-descriptive and it's actually that the token doesn't match rather than that it doesn't exist? In previous answers to this question people just say "oh, you have to add the token," which is obviously not helpful here.
Are you submitting the form manually through Ajax? If that's the case, you need to pass the anti forgery token as another parameter with the name "__RequestVerificationToken".
Point 1 : Make sure if your application is has https secure protocol. Please load in https.
Point 2 : In case of DevExpress you have to call in the below pattern.
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
After struggling with this for days I had a thought - maybe the browser is stopping the cookie being written. I did a search for dev servers and cookies not being written, and found that with Chrome and IE10 and up that there's problems writing the cookies.
I downloaded Firefox and tried it with that and it worked instantly. I then reapplied all the validate attributes to the all the controller methods and the all worked, every single one of them! Even the DexExpress postbacks seem to be working correctly.
I'll carry out more exhaustive testing, but for now, I think we're there.
Not exactly. If MVC AntiForgeryToken is already defined on page where you are using MvcxGridView and you want to protect grid actions you should send this token back to server during grid client side begin callback event.
settings.ClientSideEvents.BeginCallback = "function(s,e) { e.customArgs[\"__RequestVerificationToken\"] = $('input[name=\"__RequestVerificationToken\"]', $(s.GetMainElement())).val(); }";
I don't have any code to show, because I'm not sure how to approach this. I am sending a user from one view to another where we will be doing CRUD OPERATIONS, I need to have a way of knowing what the last view I came to before the CRUD OPERATION so that I can send my user back to that view. I would also like to use this for redirection once someone has logged in. I want to have a way of setting the view I want them to get sent back to so that they can log in from any page on the site and it will remember that page instead of just dropping you on the home page.
I would accept a good tutorial as well, I'm pretty desperate to figure this out. SHoudl I just use ViewBag?
If you making <a></a> Through Html Helper then you globally set the querystring in function that can be later used for know the last view user visit.
As Balachandra mention you can use ReturnUrl inside the Request object.
Some other idea which can help you are
Request.Server["HTTP_REFERER"]
Request.UrlReferrer
A another simple algorithm to solve this issue is making JavaScript cookie to know what is current url. and last url. it's only take 2 url to remember in cookie.
When you want to know last referrer then you can easily look in user cookie to know the referrer.
If you want to know the url refeffer in inside Action then make a ActionFilter and just call this code
HttpContext.Current.Request.UrlReferrer.ToString()
In ASP.NET MVC we have TempData which used to pass Data from Views to Views. From this post http://www.rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications You can get better explanation.
This are enough Tricks to pass the data from Views to Views. For Example TempData will help you to store current url and you can get same information on next view. Remember that TempData is based on Session so it doesn't store the information for long time. For me TempData look perfect solution that you need to use for your own solution.
If you enable asp.net mvc authentication and try to browse any page in application, it will redirect user to login page with 'ReturnUrl' querystring parameter. This parameter holds the name of previous page from where user redirected from.
You can use similar approach even after login as well.
I have a page tab app that I am hosting. I have both http and https supported. While I receive a signed_request package as expected, after I decode it does not contain page information. That data is simply missing.
I verified that like schemes are being used (https) among facebook, my hosted site and even the 'go between'-- facebook's static page handler.
Also created a new application with page tab support but got the same results-- simply no page information in the signed_request.
Any other causes people can think of?
I add the app to the page tab using this link:
https://www.facebook.com/dialog/pagetab?app_id=176236832519816&next=https://www.intelligantt.com/Facebook/application.html
Here is the page tab I am using (Note: requires permissions):
https://www.facebook.com/pages/School-Auction-Test-2/154869721351873?id=154869721351873&sk=app_176236832519816
Here is the decoded signed_request I am receiving:
{"algorithm":"HMAC-SHA256","code":!REMOVED!,"issued_at":1369384264,"user_id":"1218470256"}
5/25 Update - I thought maybe the canvas app urls didn't match the page tab urls so I spent several hours going through scenarios where they both had a trailing slash or not. Where they both had a trailing ? or not, with query parameters or not.
I also tried changing the 'next' value when creating the page tab to the canvas app url and the page tab url.
No success on either count.
I did read where because I'm seeing the 'code' value in the signed_request it means Facebook either couldn't match my urls or that I'm capturing the second request. However, I given all the URL permutations I went through I believe the urls match. I also subscribed to the 'auth.authResponseChange' which should give me the very first authResponse that should contain the signed_request with page.id in it (but doesn't).
If I had any reputation, I'd add a bounty to this.
Thanks.
I've just spent ~5 hours on this exact same problem and posted a prior answer that was incorrect. Here's the deal:
As you pointed out, signed_request appears to be missing the page data if your tab is implemented in pure javascript as a static html page (with *.htm extension).
I repeated the exact same test, on the exact same page, but wrapped my html page (including js) within a Perl script (with *.cgi extension)... and voila, signed_request has the page info.
Although confusing (and should be better documented as a design choice by Facebook), this may make some sense because it would be impossible to validate the signed_request wholly within Javascript without placing your secretkey within the scope (and therefore revealing it to a potential hacker).
It would be much easier with the PHP SDK, but if you just want to use JavaScript, maybe this will help:
Facebook Registration - Reading the data/signed request with Javascript
Also, you may want to check out this: https://github.com/diulama/js-facebook-signed-request
simply you can't get the full params with the javascript signed_request, use the php sdk to get the full signed_request . and record the values you need into javascript variabls ...
with the php sdk after instanciation ... use the facebook object as following.
$signed_request = $facebook->getSignedRequest();
var_dump($signed_request) ;
this is just to debug but u'll see that the printed array will contain many values that u won't get with js sdk for security reasons.
hope that helped better anyone who would need it, cz it seems this issue takes at the min 3 hours for everyone who runs into.
In an ASP.NET MVC 4 website I'm using Web API to return JSON-formatted resources including links for authorized actions (e.g., DELETE). To create these links I'm using the GetUrlHelper() extension method on the HttpRequestMessage...
_httpRequest.GetUrlHelper().Link( routeName, routeValues );
My concern is that the string returned from Link() is a fully qualified URL (it includes the https://example.com/...) when all I think I need is the relative URL (just the /my/resource). Currently, I've got a server problem where our production environment is adding http when it should be https, which doesn't work. I can fix that separately, but it raises the question, should I just supply a relative URL? And if so, is there a better way of getting a relative URL than trimming off the root part of the UrlHelper.Link()-generated URL?
Edit:
After consulting Richardson's & Ruby's meritorious RESTful Web Services, I believe more firmly that a relative URL is wholly appropriate here.
Does the PathAndQuery on Uri help you?
Example: (new Uri(_httpRequest.GetUrlHelper().Link("DefaultApi", new { controller = "Values", p1="abc" }))).PathAndQuery...this would give you like /my/resource?p1=abc
I'm trying to achieve urls in the form of http://localhost:9294/users instead of http://localhost:9294/#/users
This seems possible according to the documentation but I haven't been able to get this working for "bookmarkable" urls.
To clarify, browsing directly to http://localhost:9294/users gives a 404 "Not found: /users"
You can turn on HTML5 History support in Spine like this:
Spine.Route.setup(history: true)
By passing the history: true argument to Spine.Route.setup() that will enable the fancy URLs without hash.
The documentation for this is actually buried a bit, but it's here (second to last section): http://spinejs.com/docs/routing
EDIT:
In order to have urls that can be navigated to directly, you will have to do this "server" side. For example, with Rails, you would have to build a way to take the parameter of the url (in this case "/users"), and pass it to Spine accordingly. Here is an excerpt from the Spine docs:
However, there are some things you need to be aware of when using the
History API. Firstly, every URL you send to navigate() needs to have a
real HTML representation. Although the browser won't request the new
URL at that point, it will be requested if the page is subsequently
reloaded. In other words you can't make up arbitrary URLs, like you
can with hash fragments; every URL passed to the API needs to exist.
One way of implementing this is with server side support.
When browsers request a URL (expecting a HTML response) you first make
sure on server-side that the endpoint exists and is valid. Then you
can just serve up the main application, which will read the URL,
invoking the appropriate routes. For example, let's say your user
navigates to http://example.com/users/1. On the server-side, you check
that the URL /users/1 is valid, and that the User record with an ID of
1 exists. Then you can go ahead and just serve up the JavaScript
application.
The caveat to this approach is that it doesn't give search engine
crawlers any real content. If you want your application to be
crawl-able, you'll have to detect crawler bot requests, and serve them
a 'parallel universe of content'. That is beyond the scope of this
documentation though.
It's definitely a good bit of effort to get this working properly, but it CAN be done. It's not possible to give you a specific answer without knowing the stack you're working with.
I used the following rewrites as explained in this article.
http://www.josscrowcroft.com/2012/code/htaccess-for-html5-history-pushstate-url-routing/