I have an MVC application that also includes an ASP.Net WebForm to host the MS ReportViewer Web Control. We make extensive use of WebAPI to allow for client posting from Knockout viewmodels client side.
In this application, we're making use of cookies to maintain a few minor pieces of user data--a GUID, an int, and a bool.
What we see at present is that the application works correctly until a user opens the ReportViewer. At that point, we're no longer able to read any cookies from the request headers. This has been consistently reproduced in several browsers.
Examination with Fiddler has revealed that the cookies are properly posted to the server. In the first case, the cookie value is as follows:
theCulture=en-US; ASP.NET_SessionId=uhmquapd1bgghpmfgy24oodf; .ASPXAUTH=6BC2F53F9CA0CF5A437998B206B564B28B5AB362153E6E0629C9142F9E3A0285494F674716A126E4632A932BCE12CE094FE590911CE5E97EA42D0C610A44D8462A15BA9A54760883DDF712B5B199C136413667954F094FEBA2A57826BC84702A4D90D7382E360594ABC2F9EBDCEE696B4662077F; special=theId=1077b59a-100d-429b-b223-f8f0508fdc27&staffingId=77096&isBackupUser=False
In the second case, after opening the ReportViewer, our cookies are as follows:
theCulture=en-US; ASP.NET_SessionId=uhmquapd1bgghpmfgy24oodf; .ASPXAUTH=6BC2F53F9CA0CF5A437998B206B564B28B5AB362153E6E0629C9142F9E3A0285494F674716A126E4632A932BCE12CE094FE590911CE5E97EA42D0C610A44D8462A15BA9A54760883DDF712B5B199C136413667954F094FEBA2A57826BC84702A4D90D7382E360594ABC2F9EBDCEE696B4662077F; special=theId=1077b59a-100d-429b-b223-f8f0508fdc27&staffingId=77096&isBackupUser=False; /Reserved.ReportViewerWebControl.axd%3FOpType%3DSessionKeepAlive%26ControlID%3Dc3b959ab1a7c42e6a9fed5d2762a8c86_SKA=1
At which point we can no longer read them from WebApi. The method that returns the cookie in the WebAPI Controller is this:
public OurType GetApproverInfo()
{
OurType data = new OurType();
CookieHeaderValue cookie = Request.Headers.GetCookies("special").FirstOrDefault();
CookieState cookieState = cookie["special"];
data.Id = Guid.Parse(cookieState["theId"]);
data.StaffingId = Int32.Parse(cookieState["staffingId"]);
data.IsBackupUser = bool.Parse(cookieState["isBackupUser"]);
return data;
}
Anyone else seen something like this?
UPDATE: I've just learned that creating a cookie with a leading / in the name causes the same behavior in WebAPI.
What I see is that the ReportView is messing up the cookie. Probably you're setting up the cookie somewhere in the WebApi that has not the same pipeline execution sequence as the ReportView Handle.
Heres the WebApi life cycle: ASP.NET WEB API: HTTP MESSAGE LIFECYLE
But, you can override the ReportViewerServerConnection, using IReportServerConnection, and there persist yours cookie pattern.
Take a look here: Web.config Settings for ReportViewer
Another way should be setting up the cookie in a Custom IHttpModule, integrated into the ASP.NET pipe line, and then target both, WebApi and ReportView
Related
Currently I have a slack button in my WPF application that opens a webpage and asks for user for access.
System.Diagnostics.Process.Start("https://slack.com/oauth/authorize?scope=client&client_id=XXXXXXXXXXXXXXXXXXXXXX");
After authorizing, the page gets redirected to a URL which has a generated code in the parameter that I need to get a token later on. The problem is how do I get this code. For now I have set the the redirect URL to, www.slack.com. And the following url is generated.
https://slack.com/?code=8XXXXXXXXXXXXXXX.XXXXXXXXXXXXXX5&state=
How do get the code back into my application. I am using the following but am not getting the response I need and this executes before the user can even authorize.
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(URL);
var response =req.RequestUri.ToString();
Alternative solutions and suggestions would be good to implement my authorization for a desktop application using C#.
As part of the oauth process Slack will call your application using the redirect url and return the code parameter. So you the redirect URL needs to point to your application. Not to slack.com.
You will need to read the url parameters that your application as been called with. In C# that can be done with code = Request.QueryString["code"];
Your c# application needs to run as ASP script on a webserver that is accessible from the Internet, so that Slack can reach it.
In order to use Slack for authentication your application needs to implement the complete oauth process as described here.
Recently I have attended a training in mvc. The trainer said that - As per the security concerns we have to use HttpPost instead of HttpGet. Always use HttpPost.
Can anyone explain - what is the security issue when we use HttpGet?
When transmitting data over secure connection (https) body of the post request is encrypted and practically undreadable, you can only see address where data is going but not the data itself. Get on the other hand has no body and data has to be transmitted in either query string or as a path parameter. While it is true that query string does get encrypted as well, due to request logging on the server and browser it is possible to get hold of that data.
Anyone can insert image on public forum or stackoverflow with link to your web-site. Then happens next:
Browser looks at url in image tag
Browser find cookies corresponding to domain in url
Browser sends request to url with cookies of user
Your server performs action
Browser tries to parse response as image and fails
Browser renders error instead of image
But if you mark your action as Http Post only then this scenario isn't applicable for 90% of sites. But you should also consider that if hacker can create a form on other web-site then he still can make browser to perform request. So you need CSRF. Well, browsers made a lot to prevent cross-site requests, but it's still possible in some scenarios.
i have a legacy 3rd party application which submits data to our internal sales system. It exposes ASP page with a form to the internet as follows:
<form id="ServiceRequest" enctype="multipart/form-data" method="post" action="AddToServiceRequest.csp">
where AddToServiceRequest.csp is a proprietary IIS handler:
Right now we embed this form into our ASP.Net 4 website using iframe - and that is really inconvenient. What I want to do is to replace this form with a native form, do all validation etc - and then call AddToServiceRequest.csp handler from code-behind logic. What's the right way to do it? I can think only about something like this:
var r = (HttpWebRequest)WebRequest.Create("http://localhost/AddToServiceRequest.csp");
r.Method = "POST";
r.KeepAlive = false;
// fill in form data
var res = r.GetResponse();
res.Close();
but it just does not look "right" to me. Are there any other ways?
If handler serving request is for some other site (from IIS point of view) than code for it will run in separate process or separate AppDomain and you will have no reasonable way to call it directly.
If handler is registered for the same site as yours you may be able to invoke it directly - i.e. if it is APS.Net class that handles request than it just an interface with couple methods - you may be able to instantiate and execute it directly. Note that many handlers depend on HttpContext.Current and you may not be able to set request reasonably for such calls.
It is also unlikely to register same handler to your site as most handlers/controllers/forms are designed to work for particularly configured site (i.e. Web.Config will have DB connection info).
So making direct web request is most straightforward solution. I would not try any other way as most web code will not handle unusual ways of invocation correctly.
You may consider HttpClient instead of WebRequest to get easier async supoprt (assuming .Net 4.5+), but any way of setting up request is ok.
Note that if site uses Windows Authentication you may not be able to pass user information via Web request .
I cannot get session data from while in web api 2. I have verified that the cookie is sending in fiddler.
I know that web api 2 best practice is to be stateless, but due to requirements on a project it is now necessary to be state-full.
I have tried this link.
WebAPI 2 attribute routing enable session state
var session = SessionStateUtility.GetHttpSessionStateFromContext(HttpContext.Current)
With the above solution I am getting a null exception on that function.
I also tried replicating the way of doing this the way you would in the old web api by modifying the requesthandler from the route, but that is not available in web api 2.
I currently set some session variables in mvc5. This works and the session stays, but anytime I am trying to use session while in web api 2 the below is null.
HttpContext.Current.Session
Add
protected void Application_PostAuthorizeRequest()
{
System.Web.HttpContext.Current.SetSessionStateBehavior(System.Web.SessionState.SessionStateBehavior.Required);
}
to global.asax
If PostAuthorizeRequest doesn't work, then try BeginRequest.
I created a simple page using the code provided by this page (the first sample):
http://www.dotnetopenauth.net/developers/code-snippets/programmatic-openid-relying-party/
But I can't seem to get it to work, I can redirect to the provider but when the provider redirects back to my page, I get error 500, "The request was rejected by the HTTP filter".
I already checked ISAPI filters which I have none.
I've never seen that error before. Is this page hosted by the Visual Studio Personal Web Server (Casini) or IIS? I suspect you have an HTTP filter installed in IIS (or perhaps your web.config file) that is rejecting the incoming message for some reason.
Note that you need to turn off ASP.NET's default page request validation on any page that can receive an OpenID authentication response because those responses can include character sequences that look like HTML/Javascript-injection attacks but in fact is harmless.
I discovered that I'm using Isa in the server, so I just followed this instructions to get it working.
http://blog.brianfarnhill.com/2009/02/19/sharepoint-gets-the-error-the-request-was-rejected-by-the-http-filter/