We Keep Coding

ASP NET Web API google authentication issue HTTP 404

I am trying to setup a social login for my site.
Here is what I did:
I created credentials on google and have both ClientID and Secret
In default MVC app, in App_Start Startup.Auth.cs I uncommented
app.UseGoogleAuthentication()* method, so it looks like this:
Build solution!
Made sure authorized JavaScript origins and Redirect url are correct. And other things that are needed on console.cloud.google.com are done. Including activation of Google+ API
Eventually Google authentication button should appear in _ExternalLoginsListPartial partial view. But as I can see I have 0 login providers still. And not sure why, and what can I do about it?
var loginProviders = Context.GetOwinContext().Authentication.GetExternalAuthenticationTypes();
//loginProviders.Count() here returns 0
Tried researching, but most are saying that you forgot to build, or restart the server. Tried that but nothing changed.
As last resort, I tried following a tutorial https://youtu.be/WsRyvWvo4EI?t=9m47s
I did everything as shown there, I should be able to reach api/Account/ExternalLogins?returnUrl=%2F&generateState=true url, and receive callback URL from Google.
But I got stuck with same HTTP404 error at 9:50

To answer my question, everything turns out to be fine.
All I had to do was just to give it some time.
After couple of hours, Google provider appeared on the page.

For future readers - if met with 404 in this case, another possibility is an active filtering rule against query strings in IIS. One of the commonly copy-pasted rules aiming to block SQL injection requests scans the query string for open (to catch OPEN cursor). Your OAuth request probably contains this word in the scopes section (data you want to pull from the Google profile)
IIS -> Request Filtering
Switch to the tab "Rules"
Inspect and remove any suspicious active filters there

Asp.net mvc Specified UserAgent no session Id

I have a problem with my project Asp.net mvc 1.0, with .net framework 2.0. My application is hosted on a IIS 7.5. My authentication form looks like this:
<authentication mode="Forms">
<forms protection="All" loginUrl="~/Account/LogOn" timeout="60" cookieless="UseUri" />
</authentication>
<httpRuntime executionTimeout="1000" maxRequestLength="600000" />
<sessionState mode="InProc" cookieless="UseUri" timeout="60">
</sessionState>
When a user connects to the webpage, he receives a session id which is stored in the URL. When I connect to my webpage with the default UserAgent (in every browser, Chrome/FF/IE) everything works fine. When I override the browser UserAgent and try to connect with the User agent XXXXXXXX.UP.BROWSER, I receive an infinite redirection loop to address
http://<IP>_redir=1
But when I connect to the default webpage IIS - the user agent doesn't matter and everything loads fine, so it must be a problem with the specified UserAgent and my Application. I tried to find any filters for that XXXXXXXX.UP.BROWSER UserAgent but there aren't any. When I studied application lifecycle I tried to find the differences between good connection and wrong connection and found that functions which are NOT executed are:
Application_AcquireRequestState
Application_PostAcquireRequestState
Application_PreRequestHandlerExecute
Application_PostRequestHandlerExecute
Application_ReleaseRequestState
Application_PostReleaseRequestState
Application_UpdateRequestCache
Application_PostUpdateRequestCache
and another clue I found is that there is no Session in "wrong" connection - Session object is null.
To sum it up: The connection to my application web page with a specified user agent makes an infinite redirection loop, probably because of the lack of the session ID. What could be the problem ?
EDIT: I discovered that User Agent that contains "UP.Browser" is related to mobile. When I changed cookieless to "UseCookies" everything works. Why option "UseUri" doesn't work for mobiles?
EDIT2 : /admin -> my webpage hosted on specified IP address.
Good connection :
Wrong connection:
Sorry, I don't know how to make these images bigger.

http://msdn.microsoft.com/en-us/library/aa479315.aspx
So you're putting two different values into the URI, one for session and one for forms, which would probably create a lengthy URI:
"The principal limitation of this feature is the limited amount of data that can be stored in the URL. This feature is not targeted at common browsers such as IE, since these do support cookies and do not require this feature. The browsers that do not support cookies are the ones found on mobile devices (such as phones), and these browsers typically severely limit the size of the URL they support. So, be careful when you use this feature—try to make sure that the cookieless string generated by your application is small."
My guess is that the key to the infinite redirect loop is this functionality:
"// Step 5: We can't detect if cookies are supported or not. So, send a
// challenge to the client. We do this by sending a cookie, as
// well as setting a query string variable, and then doing a
// redirect back to this page. On the next request, if cookie
// comes back, then Step 3 will report that "cookies are
// supported". On the other hand, if the next request does not
// have any cookies, then Step 4 will report "cookies not
// supported".
SetAutoDetectionCookie();
Redirect(ThisPage + Our_auto_detect_challenge_variable);"
Unfortunately, this sounds like a bit of an architecture rethink, as it's probably going to now matter what the full path to your site is and you may have to drop automatic handling of forms authentication.

As you said the issue is for mobile browsers, I think this issue is limited to the devices(MOBILE) where the cookies are not supported and the Size of the URL increases and mobile browser severely limit that size, as mentioned in the MSDN reference article above.

My solution was to change User Agent containing "UP.Browser" to something else using rewrite rule. Everything works fine ;)
Edit: I found another clue.
In mobile browser - these with user agents containing "UP.Browser", it was necessary to add slash at the of the address.
In conclusion:
Everything works fine for user agents not related with "UP.Browser".
User agents containing "UP.Browser" needed address like:
http://addr/controller/
I don't know why it is necessary. Any ideas?

Google+ signin "Getting Started" project - problems with IIS

Using the C#/.NET Google+ sign-in quick start project, I'm hitting problems with IIS6. Here are the steps I followed:
downloaded the project from Github
modified the index.html and signin.ashx files to contain my Client ID and Client Secret
running the project on my machine (using the built in web server for Visual Studio 2010) works fine
published to Windows 2003 server with IIS6
added "index.html" as a default document for the web site
set the web site to use an app pool configured for the 4.0 .NET framework
attempted to access the page from Chrome
Accessing the site with no page specified on the URL (https://myserver.com/gplussample/) brings up the Google+ signin button. This works great and I'm taken to the page with my profile photo, circles, etc.
However, when I click the "disconnect" button, nothing happens. Using Chrome DevTools to examine the process, I see this error:
POST https://myserver.com/gplussample//disconnect 404 (Not Found)
The problem is the //disconnect - there's no page name (I believe it should be signin.ashx, as that's what works when I'm running the app on the dev web server with Visual Studio 2010).
I then attempted to access the site with a page name specified:
https://myserver.com/gplussample/signin.ashx
That results in a blank page and again, looking at the Chrome DevTools, I see a 400 Bad Request error for the .ashx handler. I searched and searched for solutions for .ashx handlers and "bad request" errors, with no success in this particular case.
Thinking IIS6 was the culprit, I published the site to an IIS7 instance.
With no page name specified on the URL (http://localhost/gplusoriginal/), I encountered the same error with the "disconnect" button - no action and a 404 error.
When I changed the URL to http://localhost/gplusoriginal/signin.ashx, I received this error:
Could not create type 'GPlus_ServerSideFlow.Signin'.
Again, back to Google and checking on .ashx handlers and issues with IIS7. I found a post about the web.config and specifying the handler there, so I tried that.
<system.webServer>
<handlers>
<add name="GPlus_ServerSideFlow.Signin" path="*.ashx" verb="*"
type="GPlus_ServerSideFlow.Signin" resourceType="Unspecified" />
</handlers>
</system.webServer>
Adding this snippet to the web.config resolved the "could not create type" error, but resulted in another 400 Bad Request error.
So, my questions are: What has to be done with II6 or IIS7 to get this sample project working? Are there additional steps in configuring IIS that need to be completed? Or something missing from the project code?
Thank you

The way that the sample works is that the RESTful endpoints are intercepted by an ashx handler, signin.ashx.cs. The handler can't be directly addressed so routes are setup in global.ashx.cs to map endpoints (/, /connect, /disconnect, etc) to that route handler.
As the sample ships, it assumes the built-in web server running on the root port. When moving to IIS, you need to change the path matchers from Equals to EndsWith in order to match the virtual directory you are deploying to:
// Redirect base path to signin.
if (context.Request.Path.EndsWith("/"))
{
context.Response.RedirectPermanent("signin.ashx");
}
// This is reached when the root document is passed. Return HTML
// using index.html as a template.
if (context.Request.Path.EndsWith("/signin.ashx"))
{
Apologies for the delay on this... but hopefully that fixes it! This fork of the C# starter has the changes in it, tested with IIS, and this update may end up getting merged back into the official sample soon.

Why does DotNetNuke log me out on post ajax requests?

Previously, when I tried to do an ajax call to an ashx as a non-superuser account (i.e. as portal specific user) my web server would return cookies to clear my authorization. I posted a question about this and it seemed the answer was to make sure that the portalid=xx was specified in my GET parameters.
However, I have just found out that if I add portalid=xx in a POST request, DotNetNuke seems to ignore and and log out any non-superuser account.
How can I keep authorization during DNN POST ajax requests?

I think I have a good handle on the whole situation, and unfortunately it appears that the only true solution is to make sure each child portal has its own subdomain rather than a sub-url (e.g. portal.domain.com rather than domain.com/portal).
The problem is that when your portal 0 is domain.com but portal 1 is domain.com/portal everything works correctly until you need to access an .ashx file via ajax. What happens then is the URL that's requested is instead domain.com/DesktopModules/MyModule/Handler.ashx, which does not contain the /portal/ in it, thus causing DNN to think you are doing a request on portal 0 and logging you out.
While GET requests can overcome this with a portal=1 parameter, this does not seem to work for POST requests.
Therefore, the best solution it seems is to have your portal on a distinct subdomain (portal.domain.com), and then you don't risk missing something like this.

I've found a few things for you to check out and see if any of them solve your problem.
Make sure you are using a ScriptManagerProxy. This allows ascx pages to use AJAX while the parent page is also using AJAX.
There have been many reports of people not being able to run AJAX with DNN if Page State Persistence is set to "Memory". Those who experience this have been able to fix it by switching Page State Persistence to "Page". The easiest way to do this is to run this query:
update HostSettings
set SettingValue='P'
where SettingName='PageStatePersister'
After you run that, you'll need to recycle the application. If you don't have access to the server, just add a space or carriage return to your web.config file (that will force the app to recycle).
Lastly, you might see if you have this line in your web.config. Sometimes removing it will help:
<system.web>
<xhtmlConformance mode="Legacy" />
</system.web>

Response.Redirect going to wrong destination

I am working on a c# .NET website in which the user can click on a link and get redirected to another web page in a separate website also owned by us. The code is very easy to understand, there is a switch followed by a call to Response.Redirect(the_url_we_want_to_go_to).
I have debugged it numerous times and I can confirm that when the debugger hits this redirect line that the parameter is correct. It points to the QA version of this other website. qa.samplesite.com lets say. However, the browser does not go there. The browser instead hits the test environment instead. Lets call it test.samplesite.com. This is the problem.
I understand there are a million things in between the app servers these two separate websites are on, but maybe one of you has seen something like this before. More specifically, is there a way to catch outbound traffic in the debugger or is there a way to see outbound traffic on the app server itself (in IIS)? I am familiar with intercepting inbound traffic inside of httpmodules. Maybe this isnt a stackoverflow question...
Thanks for your help!

Use the very nice HTTP sniffer "Fiddler". It will allow you to see all HTTP requests. You should verfiy that a) the redirect target is correct (it might be overwritten later in the request pipeline. A Response.Redirect is not the final word) and b) that you don't have a second redirect after the first one.

You can try using the overload of Response.Redirect as
Response.Redirect("url_here", true);
This will stop the response on current page (as endResponse is set to true) and redirect to the url.
If you still have the issue, then this might be some name resolution error.
Check to see you your hosts files in the windows directory found here
C:\Windows\System32\drivers\etc\hosts
Hope this will do it.

I finally figured a similar issue I had. It was quite silly. I had copied some .aspx pages making minor changes. The page where I tried to redirect the client, had it's "CodeBehind" setting wrong. So it redirected to the right page, but loaded the CodeBehind from another page!