We have upgraded both our application running openiddict and the client application in question to .net core 3.1 and .net framework 4.8 respectively. Openiddict is also updated to 3.1.0
Since this update, and the resulting changes in both projects, our .net framework asp.net mvc 5 application began hitting exception
IDX21323: RequireNonce is 'System.Boolean'. OpenIdConnectProtocolValidationContext.Nonce was null, OpenIdConnectProtocol.ValidatedIdToken.Payload.Nonce was not null. The nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'. Note if a 'nonce' is found it will be evaluated.
Upon inspection of the redirect request from our connect/authorize endpoint back to the client application's signin callback (called signin-sevanidentity) we see that instead of receiving a cookie of OpenIdConnect.nonce like we see on our production instance we see .AspNetCore.Identity.Application which is not being recognized by the client
Callback in updated version:
OpenIdConnect.nonce Header Info
Callback in working production instance:
ProductionHeaderInfo
Not certain if I've messed up config in openiddict, the client or both.
I found the resolution for this specific issue. The root cause was because I was using the incorrect response type in my client side's OpenIdConnect configuration. I was using "code id_token" instead of "code"
When I went to modify the OpenIdConnectResponseType enum value I found that code was not one of them, only 2 options were.
It turns out I had mistakenly installed an unneeded package that overrode the extensions.
Microsoft.IdentityModel.Protocol.Extensions published by "Microsoft Corporation" not "Microsoft"
Nuget Package name and version
After uninstalling this package I was able to add the code response type as intended.
Related
I'm using WebApi Core 2.2. The Microsoft OData Client is adding a new parent record plus a subrecord (Deal+DealFee) from a WPF application. I'm hosting in IIS on Windows 10.
When I call container.SaveChanges(), it successfully calls the service to add the parent Deal record, but then it does a SECOND POST operation to this url (this is generated by the MS odata client lib):
POST http://localhost/mysite/odata/Deals(14)/DealFees
(note this includes the ID 14 which was just generated when adding the Deal)
This is two separate POSTs from the MS odata client lib, not a "deep insert" apparently. However, this results in a 404 (NotFound), which I can observe in Fiddler. The following urls DO work perfectly:
/odata/Deals
/odata/Deals(14)
/odata/DealFees
It seems like either the WebApi Core 2.2 service is not handling the POST to /Deals(14)/DealFees path, OR /Deals(14)/DealFees isn't a valid odata Uri? Is this kind of path generally supported in OData?
I don't know. Can anyone shed some light on what's going on?
Deep insert is not supported in WebAPI OData as of now. To me, it seems like the client is updating the resource set and the resource set for the navigation with two separate post requests and the reason you are getting a 404 is that there is no action mapped to the second request URI in the service.
The service can support this either by introducing a PostToDealFeesFromDeals controller action with default OData routing convention or use attribute routing to map the action for such requests.
If the action already exists then it might be that the first request did not finish creating the new record and the second request was fired, hence 404.
I'm using openiddict on a .net core 1.1 project. So far i was able to login through /connect/token endpoint.
Suddenly, without any changes to the controller i get the following exception
InvalidCastException: Unable to cast object of type
'AspNet.Security.OpenIdConnect.Primitives.OpenIdConnectRequest' to
type 'OpenIddict.OpenIddictOptions'.
Is there anyone else having the same issue?
API changes have been introduced in ASOS 2.0.0-rc1-final that are incompatible with the exact OpenIddict version you're using. To fix that, remove the packages that start with AspNet.Security.OpenIdConnect from your .nuget\packages folder and restore your project when it's done.
I'm new to ASP.NET Web API and I'm struggling with a very strange problem.
I have some code which calls a RESTful service and it executes fine from a console project, but I can't get it to run from an MVC4 project running under .NET 4.0
The code to call the service is very simple:
internal string Test()
{
using (var client = new HttpClient())
{
client.BaseAddress = new Uri("https://testserver");
var task = client.GetAsync("/someUri")
var response = task.Result;
response.EnsureSuccessStatusCode();
return response.Content.ReadAsStringAsync().Result;
}
}
As mentioned, called from a console project it works as expected and I get a response in milliseconds, however if I call the method from an action in my MVC4 controller after a few seconds I get a message stating that:
"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to repond".
Weirdly, when debugging the MVC4 version, the task status always shows as WaitingForActivation.
Running fiddler doesn't show any request being made from the MVC4 version, but again does for the Console version.
After a fairly serious bit of googling I can't find anyone else who seems to have had this problem, so I'm guessing that I've fundamentally misunderstood something, but at the moment I'm not sure what!
Updated 16:55 BST, 11/09/2012
To make things even weirder, I've just created a new MVC4 site and I can call the method without any problems! I'm now trying to compare the sites, however one was an existing site that was upgraded to MVC4 and the other is a new blank site, so spotting the relevant difference could be tricky.
Updated 16:44 BST, 14/09/2012
This is now looking like some infrastructure / networking issue.
I upgraded the project to VS2012 with .NET 4.5 so that I could use async/await to try the suggested implementations to avoid a deadlock. This didn't change anything so I went back to square 1.
I created a new solution with a new MVC4 project, a new services library and a unit test project to run the service library outside of MVC.
In the service library I created one method to call a public "what's my IP" service, and another to call a company service that's exposed publicly but only responds properly to company IP addresses.
For some background, I connect in to the company LAN via a VPN.
When disconnected from the VPN, in both unit tests and MVC, the IP service responds HTTP 200, the company service responds HTTP 404 as expected.
When connected to the VPN, unit tests both respond HTTP 200, MVC both timeout.
Next I ran MS Soap Tool locally and used that to proxy calls to the company services. All calls (whether from unit tests or MVC) show a request and response, but the unit test registers the response whilst the MVC controller does not.
My only other thought is that it could be something to do with the size of the reply? All the "successes" have very small replies other than the unit test calling the company service?
The Microsoft recommended way to upgrade an MVC3 to MVC4 site is to start with a completely new MVC4 site a migrate your views, controllers & code over. So I think that your upgrade steps may be part of your issue, since you were able to get it to work in the new MVC4 site you created. If you need to manually upgrade your existing site, I would follow the steps outlined in Upgrading ASP.NET MVC 3 Project to ASP.NET MVC 4
I am working on the fastest way to write cookies from a WCF self hosted console app REST service with WebHttpBinding.
I prepare the "Set Cookies" but only the first cookie is set in the browser (using FireFox 11.0 on Windows) as well as the "Expires" value.
var expiry = DateTime.Now.AddMonths( 6 );
var outresp = WebOperationContext.Current.OutgoingResponse;
outresp.Headers.Add( HttpResponseHeader.SetCookie , "cookie1=fd9416ea-2705-4d44-be76-f2f7b95e6b13; cookie2=7d489e69-d9c9-4b8d-a4b1-bce0da1c5966;expires=" + expiry );
I also tried putting a comma between the first cookie and the second one, that did not work either:
outresp.Headers.Add( HttpResponseHeader.SetCookie , "cookie1=fd9416ea-2705-4d44-be76-f2f7b95e6b13;, cookie2=7d489e69-d9c9-4b8d-a4b1-bce0da1c5966;expires=" + expiry );
I cut this down, and fired up Fiddler:
outresp.Headers.Add( HttpResponseHeader.SetCookie , "foo=foovalue;,bar=barvalue;" );
and Fiddler shows this:
Response sent 27 bytes of Cookie data:
Set-Cookie: foo=foovalue;,bar=barvalue;
This response did not contain a P3P Header.
Validate P3P Policies at: http://www.w3.org/P3P/validator.html
Learn more at: http://www.fiddler2.com/redir/?id=p3pinfo
Which tells me that I am not formatting things on the .NET side to make the cookies acceptable to the browser.
How can I get all of the cookies into the browser insetad of just the first value? What did I miss?
Thanks.
[ EDIT ]
I took the issue to Microsoft for support, and learned this:
The fact that "Set-Cookie" is munged into a single cookie line is logged as a bug within Microsoft for .NET Framework 4.0 and also Framework 4.5.
Within the Microsoft WCF development group, the bug is listed as "closed" and "won't fix".
According to Microsoft, the only workaround is to move from self-hosted to hosting within IIS and then using the (IIS) Response object directly (different code path that does not have the bug).
Although this is an older post, since this is still an ongoing issue and using the AspNetCompatibilityMode with WCF has significant performance downside, the option that MSFT has supplied is not viable under many/most/any circumstances. I'm going to answer this question late since this issue is still lingering.
The only way to resolve this issue is to output the Set-Cookie response header just as you've shown, but to process that response header on the client side with javascript and place it in to the browser since, as you've noted, the browser will not handle this response. Neither will applying more than one Set-Cookie response header work as noted in this bug I created.
http://connect.microsoft.com/VisualStudio/feedback/details/779111/wcf-rest-service-two-set-cookie-http-headers-invalid-set-cookie-header-syntax
So, process the response header and use document.cookie in client-side javascript to place the cookies in the browser within the success handler of your jQuery .ajax request.
To expand on #jeff-fischer 's answer, AspNetCompatibilityMode does work and requires the following:
AspNetCompatibilityRequirements is set for the service class to either Allowed or Required e.g.:
[AspNetCompatibilityRequirements(RequirementsMode
= AspNetCompatibilityRequirementsMode.Allowed)]
public class AppService : IAppService
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> is set in <system.serviceModel>
This then gives access to HttpContext (you'll need using System.Web; to get access to this) and cookies can be set using:
var aCookie = new HttpCookie("foo")
{
HttpOnly = true,
Value = "bar",
Expires = DateTime.Now.AddDays(1)
};
HttpContext.Current.Response.Cookies.Add(aCookie);
This will then need to be run as an application on IIS rather than though the WCF launcher and if multiple cookies are set, multiple cookie headers will actually appear.
We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".