I have a web app running .Net 4.5.1 and Identity 2.
In my WebApi I have an iOSLoginController.cs using code grafted from the main .NET Identity's AccountController.cs. It's being fed from my iOS app using AFNetworking 2.0.
It works fine locally in my local iis. Logs in fine. But when published to Azure, it isn't actually logging in but it still says 'success' at:
var result = await SignInManager.PasswordSignInAsync(usernameToCheck, model.Password, false, shouldLockout: false);
// switch on result
switch (result)
{
case SignInStatus.Success: <-- it says it's successful ?!?
But then if i check right away with AFNetworking in a WebView, it's not logged in and redirects to Login?ReturnURL=..c (My app is hybrid and uses Webviews for info/stats and native for login/signup and worked fine in Identity 1, this is an upgrade site)
It's not the iOS app, it is working fine against my local IIS and another regular physical server. But when I change where the base url for the API to point to the Azure machine, it's just not logging the person in... but saying success... I verified by attaching to the process in VS2015
I have set a machine key manually as well in the web.config so it won't rotate and log users out when IIS starts recycling processes.
Any ideas?
Modern browsers reference the Public Suffix List for cookie domains, which are regarded as public.
The idea of the list originally came from the need to protected top level domains, like
.com
, as it would have been possible for anyone to set a cookie for all domains ending.com
, which would affect all sites with of the top level.com
domain.The list also contains other domains considered to be public. This list is maintained by the community and the
azurewebsites.net
domain, amoung others, is part of this list.Thanks to this, it isn't possible for a person to setup an azure app and hijack cookies in other peoples apps on the shared domain.