I'm running the app using "dotnet run". If I don't set the url programmatically using .UseUrls() then it picks it up from launchSettings.json and all good. However if I set THE SAME url using .UseUrls() I get the message below on the brower.
There are no errors from the code i.e. both cases report " Now listening on: http://localhost:6001". Any ideas?
Remove Strict-Transport-Security from your Web.config
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security"
value="max-age=16070400; includeSubDomains" />
</customHeaders>
</httpProtocol>
</system.webServer>
My mistake - launchSettings.json was using https://localhost:6001 and the code was using http://localhost:6001. Doh!
Related
I am trying to include SSO with office 365 for one of our web applications.
the problem is that as soon as SSO is working all my postbacks are getting ignored.
what I did was the following,
I installed those Nuget Packages
- Microsoft.Owin
- Microsoft.Owin.Host.SystemWeb
- Microsoft.Owin.Security
- Microsoft.Owin.Security.Cookies
- Microsoft.Owin.Security.OpenIdConnect
- Owin
I created an app in my AAD
then I've added some settings to my web.config
<add key="ida:PostRedirectUri" value="http://localhost:4439" />
<add key="ida:ClientId" value="XXXXXXX" />
<add key="ida:AADInstance" value="https://login.microsoftonline.com/" />
<add key="ida:Tenant" value="XXXX.onmicrosoft.com" />
<add key="ida:PostLogoutRedirectUri" value="http://localhost:4439" />
and I added Startup.vb to my solution with the following content
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType)
app.UseCookieAuthentication(New CookieAuthenticationOptions())
app.UseOpenIdConnectAuthentication(New OpenIdConnectAuthenticationOptions() With {
.ClientId = clientId,
.Authority = authority
})
app.UseStageMarker(PipelineStage.Authenticate)
and after this the SSO works however al postbacks on buttons fail
if I click a button the page just gets reloaded.
also the IsPostBack parameter is alwayst false.
What I found was that when I remove the "app.UseOpenIdConnectAuthentication" part, postbacks are working again, but SSO is not.
how can I make sure my postbacks are working and I can also use UseOpenIdConnectAuthentication ?
thank you.
I found the issue,
in my web.config I had
<modules runAllManagedModulesForAllRequests="true">
in system.web
removing the key "runAllManagedModulesForAllRequests" solved the problem
<modules>
I have read through NWebSec's documentation to try and resolve the problem.
Set the web.config to
<nwebsec>
<httpHeaderSecurityModule
xsi:noNamespaceSchemaLocation="NWebsecConfig/HttpHeaderSecurityModuleConfig.xsd"
xmlns="http://nwebsec.com/HttpHeaderSecurityModuleConfig.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<redirectValidation enabled="false">
<allowSameHostRedirectsToHttps enabled="false"/>
<add allowedDestination="https://www.facebook.com/"/>
<add allowedDestination="http://www.nwebsec.com/"/>
<add allowedDestination="https://www.google.com/accounts/"/>
</redirectValidation>
<securityHttpHeaders>
<strict-Transport-Security max-age="365" includeSubdomains="true" httpsOnly="false" preload="true" />
</securityHttpHeaders>
</httpHeaderSecurityModule>
but I am still getting
A potentially dangerous redirect was detected. Add the destination to the whitelist in configuration if the redirect was intended. Offending redirect: https://www.facebook.com/dialog/oauth?response_type=code&
This came up in google before the answer, which is here: https://docs.nwebsec.com/en/latest/nwebsec/Redirect-validation.html
In summary you have to whitelist the URL which your login service refers to, like this:
app.UseRedirectValidation(opts =>
{
opts.AllowedDestinations( "https://www.facebook.com/dialog/oauth");
opts.AllowedDestinations("https://login.microsoftonline.com"); // Tested
});
I'm getting the following error:
WARNING: The ServicePointManager does not support proxies with the https scheme.
This started happening randomly. I'm not behind a proxy, and restarting did not fix anything.
I had the following in my machine.config file:
<system.net>
<defaultProxy
enabled = "true"
useDefaultCredentials = "true">
<proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" usesystemdefault="false" />
</defaultProxy>
</system.net>
This was causing the issue. Must have been leftover from a fiddler crash.
I am trying to redirect Spring Security to a custom login page which GWT based. Here is my configuration:
<security:http pattern="/Main.html?#login" security="none" />
<security:http auto-config="true">
<security:form-login login-page='/Main.html?#login' />
<security:intercept-url pattern="/**" access="IS_AUTHENTICATED_FULLY" />
</security:http>
From the spring security debug logs - it seems that the framework drops everything after the "#". Does anyone know how to fix this?
Thanks.
There is no way to fix this. Spring security runs on server side, and data in url after hash are never sent to the server from browser. Normally you would make a separate page for login, outside of your primary GWT application.
I have a long querystring value I need to pass in (itself a questionable practice, I understand), and I am not able to get it to take effect on my Appharbor app instance.
Locally, I've made this change to my web.config and confirmed that the URL in question works locally:
<httpRuntime maxQueryStringLength="2097151"/>
And ensured that it exists in the resultant web.config post the transformation by my Web.Release.config. That said, when I push to AppHarbor, the transformation should pick it up...yet I'm still getting this exception:
The length of the query string for this request exceeds the configured maxQueryStringLength value.
Stack Trace:
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
Any ideas? Thanks for your help.
My original testing was done against Cassini (VS 2010's built-in web server). I pushed locally to IIS 7.5 and found this error:
HTTP Error 404.15 - Not Found
The request filtering module is configured to deny a request where the query string is too long.
Which appeared because I didn't specify the maxQueryLength in the <system.webServer> section of my web.config as well as the <httpRuntime>. So the answer is to specify BOTH the <system.web> and <system.webServer> sections:
<system.web>
<httpRuntime maxQueryStringLength="2097151"/>
</system.web>
And then:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="2097151"/>
</requestFiltering>
</security>
</system.webServer>
When I pushed this version of my config to AppHarbor, all was well. Hope this helps.
Remember that HTTP.SYS has its own limits as well!
They're described here: http://support.microsoft.com/kb/820129