I have a entire site built to work with webapi2. The problem comes when i need to export a file.
In modern browsers, when i make a /Token requisition passing Login and password and them calling the mvc5 method /SomeList/Export it works fine. /SomeList/Export has no especial headers and im not passing the token, i can open this in any of the browsers windows and it still works. I dont now how. Maybe a cookie or something?
the problem is that in ie8 it dosent work. I cant use mvc5 authorized actions.
how this webapi2/mvc5 works? And if it is possible, how to make it work in ie8?
Authorization works completely differently in Web Api vs MVC. They can use the same base of user accounts, but logging into Web Api, does nothing for MVC and vice versa. Each has to be authorized separately.
Related
I am having an issue with trying to create a bot. Everything seems to work fine when I am using Http. I can deploy my application to my website and interact with the bot via the emulator or botframework.com.
Unfortunately, when I try to use HTTPS, I get a 401 error from the emulator and nothing shows up when I try to use botframework.com.
Just so that I am crystal clear, the only things that I changed are:
1. Added the [BotAuthentication] attribute to my ApiController like so:
[BotAuthentication]
public class MessagesController : ApiController
Updated the URL in the emulator/botframework.com from http://mywebsite.com/api/messages to https://mywebsite.com/api/messages
Web.config is all set up with the appId and AppSecret. My site already has an SSL certificate.
Is there anything that I am missing? Although I have never used basic authentication before I am assuming there is nothing else that I need to set up, right?
I hit your endpoing and IIS is responding to the basic auth and getting in the way.
Basic Auth is works the following way:
There is a header which contains the UserId:Password encoded as base64
If the server doesn’t see the header it returns a 403 with a “basic” to signal that the web site requires auth token. For a web browser that means it will popup a stock user/password dialog and then it will do submit the request again with the header.
If the header is provided but the user/password is wrong the server returns 401.
Normally basic auth is used to look up in a database, but in our case there is only 1 user, it is the bot appid/appsecret. All the BotAuthorization attribute does is to add an inspector to the request pipeline to look for the header with appid/appsecret in it to make sure that only approved callers can call your bot.
If you don’t care about that you can simply remove the attribute. Regardless, you don’t want IIS sticking it’s nose into the process.
Make sense?
This theoretically should work based on your description of the changes you've made. This is the emulator talking to your cloud service or to the bot on localhost? And you get this error as well from the Bot Framework test control in the portal?
If you send me your BotId to botframework#microsoft.com I can check our logs to see if there's anything interesting (or DM me at #jameslew on twitter).
We are working on an internal MVC3 app that purely uses Windows Authentication. There's a view that does an AJAX call to a controller action that does some processing before calling a web service. The problem we are running into is that if Anonymous access is turned off (as in Windows Authentication is on), calling the service from the controller actions results in a 401: Unauthorized error.
We have run into a problem of the double hop issue where credentials aren't passed correctly from server to server when calling a service within a service. I'm wondering if the AJAX call is somewhat mimicing the same behavior and not transmitting the correct Windows credentials to the controller which then doesn't pass the correct credentials to the web service.
I've seen some posts that shows how to pass a username and password along with the jQuery call but nothing mentions, an effective way, to bring along Windows Authentication with it.
Has anyone run into a similar issue? We would rather not leave Anonymous access on the web service as it is somewhat sensitive data that we would like to control access to.
Do you have identity impersonation turned on as described in this question:
How to get Windows user name when identity impersonate="true" in asp.net?
A colleague did some research over the weekend and determined it may have something to do with Kerberos authentication setup on the server as well as the jQuery call. In order to get around it, we just refactored the web service into a library that the application just references. We made it a web service initially as we thought in the future this data would need to be accessed from other applications. Running into this issue, we will most likely make it into a NuGet package.
Thanks for the comments.
We have an controller method that is being called twice. The first time it is called we get the correct parameters, the second time it is called we get no parameters and the MVC engine throws an exception because the arguments to the method cannot be null.
We have seen this behaviour before when using certain versions of Safari and it was to do with authentication. When using windows authentication if the properties of the authentication in IIS were set to Negotiate and NTLM an ajax call would get sent once for each. The fix for this was to remove one (I think we just left it as NTLM). This is not the case as we are using forms authentication here.
We have also seen similar behaviour when calling WCF methods that were returning types that were derived and not using the KnownType attributes on the parent class.
We cannot reproduce this with any success (it's happening infrequently on a clients machine) and are looking for any general gotchas.
The reason the call is being called twice is because of a bug in Safari when working with Windows Authentication under IIS. Go to the Authentication settings of your website. Right click on Windows Authentication, choose providers and remove Negotiate, leaving NTLM which works fine. I haven't tested Kerberos.
This issue only appears in certain builds of safari.
I have an IHttpHandler which I'm running on an Windows Server 2008R2, and IIS 7.5 with integrated mode. The handler should handle file uploads, triggered by a jQuery-Ajax call.
First It did not work on IIS at all, only in the VS 2010 Debugger. Somehow I did manage to register the Handler correctly and I was able to debug the HttpHandler - BUT: Asp.Net Authentication wasn't working: it always said I wasn't logged in. When I directly access the HttpHandler it all works like a charm. Only the jQuery-Ajax call drops dead.
For further information: I'm using FormsAuthentication and it all is running inside an MVC 3 Application.
Could it be related to a missing AuthCookie? I've also read this Article, but it doesn't seem to help me out: MVC + Ajax call to Controller Loses Authentication
If you need any further information / code, just ask for it, I'll post it asap.
Could it be related to a missing AuthCookie?
Yes, it could, especially if your file upload component uses Flash it might not send the authentication cookie. You may take a look at the following article for a sample workaround which consists into sending the authentication cookie value in addition to the file in the request.
I am trying to do some screen scraping accessing a forms authenticated website. I was doing some tests on an asp.net forms authenticated site that I built and it worked just great. When I tried the real site I realized it was using some kind of an Oracle forms authentication (a fiddler showed a call to a dll instead of an html file. I suppose this dll provides the html result). What I see in fiddler is:
https://{domain}/access/oblix/apps/webgate/bin/webgate.dll
The rest of the call seems similar, cookie, user name and password, just like in the regular forms authentication.
Any idea on how to crack this type of request (to a dll instead of an html)?
(By the way, the result I get is some kind of an Oracle error).
With Forms Authentication the webserver issues the client with a cookie that is used to verify the client in future subsequent requests (HTTP Basic and Digest authentication requires the client to post the "WWW-Authorization" header on every request). Are you persisting your cookies between requests?
The file extension of the url is not important to how you make your request.
It sounds like your script needs to make a request identical to the ajax request made by your browser (and shown in fiddler).