I am having trouble upgrading my current project to use RIA Services. I added all the necessary web.config changes but still no luck. I everything compiles fine but when I hit the page using the datacontext I get an error. I debugged with fiddler and I'm getting a 404 on one of the request. I am getting back headers in my grid so some communication is happening but no data is actually coming through. Another thing to note is that my MVC is running windows authentication. I do have a clientaccesspolicy.xml as well.
Error in Silverlight with Headers but no data,
Response from Fiddler:
[HttpException]: The controller for
path
'/Services/EpicWeb-Services-LegacyDomainService.svc/binary'
was not found or does not implement
IController. at
System.Web.Mvc.DefaultControllerFactory.GetControllerInstance(RequestContext
requestContext, Type controllerType)
at
System.Web.Mvc.DefaultControllerFactory.CreateController(RequestContext
requestContext, String controllerName)
at
System.Web.Mvc.MvcHandler.ProcessRequest(HttpContextBase
httpContext) at
System.Web.Mvc.MvcHandler.ProcessRequest(HttpContext
httpContext) at
System.Web.Mvc.MvcHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext
httpContext) at
System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at
System.Web.HttpApplication.ExecuteStep(IExecutionStep
step, Boolean& completedSynchronously)
Looks like all I needed was an IgnoreRoute.
First attempt was a typo.
routes.IgnoreRoute("{*allsvc}", new { allsvc = #".*\.svc(/.*)?" });
Related
I'm trying to use ITfoxtec.Identity.Saml2.MvcCore on a .NET Core 3.1 web application using an in-house IdP.
It works great on our test server (Windows Server 2012, hosted in the IIS) but I can't get it to work on any other server.
This is what happens:
The initial call to the website is correctly identified as a non authenticated call and the user is being sent to the IdP where the user logs in as usual. The SAML-token is then posted back to the web applications assertion consumer service where everything seems like it does what its supposed to, saml2AuthnResponse.Status has statuscode Saml2StatusCodes.Success and the logfile says "AuthenticationScheme: saml2 signed in". Then it reads the ReturnUrl-parameter and log something like "Executing RedirectResult" but then it just stops. Nothing in the logfile, nothing in the IIS-logs. The user is met by the message
This site can’t be reached
...
ERR_HTTP2_PROTOCOL_ERROR
In short, every controller that has the [Authorize]-attribute gives the ERR_HTTP2_PROTOCOL_ERROR-error. When I remove all [Authorize]-attributes the application works great, although without authentication.
I've also tried the example TestWebAppCore-application from ITfoxtec.Identity.Saml2's github-page and it gives the same error. It works on our 2012 test-server but nowhere else.
Any ideas that I can try?
I think you need to trace the calls to see the actual http request and responses send between the browser and server. I usually use Fiddler for tracing the requests/response. Remember to enable Fiddler for https tracing.
My first thought is that the problem can have something to do with cookies. But it is only a guess...
You might be on to something, we disabled http/2 on the server and was greeted instead by this message:
Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.
It uses 5 cookie-chunks for the SAML-data for a total of 19941 bytes which is a bit to much. I've tried to make the application save the sessiondata in classic session objects instead but I cant seem to get it to work.
This is what I added to StartUp.cs:
In ConfigureService:
services.AddMvc()
.AddSessionStateTempDataProvider();
services.AddSession(options =>
options.Cookie.IsEssential = true
);
services.Configure<CookiePolicyOptions>(options =>
{
options.CheckConsentNeeded = context => false;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
In Configure:
app.UseSession();
But it still fills up the header with cookies. What am I doing wrong? Is there a another way to make the session cookies smaller?
I'm using ASPNET Boilerplate framework for developing my application, but I'm sure this is a WebAPI Specific issue. I'm consuming a Dynamic WebAPI function that is built upon the following Application Layer function.
Application Service function
On my Angular App I'm using the following code to POST data to the Dynamic API and eventually the Application Layer function.
var formDataObject = new FormData();
formDataObject.append('avatar', vm.group.avatar);
formDataObject.append('name', vm.group.name);
formDataObject.append('description', vm.group.description);
$.ajax({
url: abp.appPath + 'api/services/app/group/CreateGroup',
processData: false,
//contentType: false,
type: 'POST',
data: formDataObject
});
I receive the following error in my Chrome console:
{"message":"The request entity's media type 'application/x-www-form-urlencoded' is not supported for this resource.","exceptionMessage":"No MediaTypeFormatter is available to read an object of type 'InputGroup' from content with media type 'application/x-www-form-urlencoded'.","exceptionType":"System.Net.Http.UnsupportedMediaTypeException","stackTrace":" at System.Net.Http.HttpContentExtensions.ReadAsAsync[T](HttpContent content, Type type, IEnumerable`1 formatters, IFormatterLogger formatterLogger, CancellationToken cancellationToken)\r\n at System.Net.Http.HttpContentExtensions.ReadAsAsync(HttpContent content, Type type, IEnumerable`1 formatters, IFormatterLogger formatterLogger, CancellationToken cancellationToken)\r\n at System.Web.Http.ModelBinding.FormatterParameterBinding.ReadContentAsync(HttpRequestMessage request, Type type, IEnumerable`1 formatters, IFormatterLogger formatterLogger, CancellationToken cancellationToken)"}
I've tried the following solutions with no success:
Use FormDataCollection as the parameter type.
Post without the file (avatar) object. Failed.
Post with application/formdata type. Failed.
All the solutions I've seen on the internet don't work for me.
Okay I solved this after many hours of debugging so if anybody else is facing the same problem can save time. This was NOT a WebAPI issue. WebAPI provides MediaTypeFormatters for 'application/x-www-form-urlencoded'. This issue was due to some implementation of Abp.WebApi package that was outdated. Update your aspnet boilerplate packages to Abp v1.0 release Sep 28, 2016. Fix the broken code. and recompile. This problem should be solved. Reach out to me if you're still having issues maybe I can help.
When calling a web service from Force.com, I am getting:
System.CalloutException: Web service callout failed: Unexpected
element. Parser was expecting element
'http://schemas.xmlsoap.org/soap/envelope/:Envelope' but found ':HTML'
The network guys at the other end has asked to see the full response that Salesforce is getting from their server.
Is there a way to achieve that? I have tried running with debug level 'Finest' from execute anonymous, but that yields the same little message with no further detail.
The message you are getting is because an error is generated as Saleforce is trying to parse the response is and it isn't logged unfortunately.
The parsing error is happening because instead of a SOAP message response you are getting an HTML page. This usually happens when you are accessing a service that is protected behind a firewall. Which means you may be able to see the service when browsing on your computer but remember that Salesforce is outside of your firewall and thus any communication by Salesforce to your service will be blocked.
Couple of ways to address this but this wiki topic from Salesforce best covers the options:
http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_om_outboundmessaging_security.htm
The above is specific to outbound messaging but essentially the technology issues are the same.
Don't forget that Apex includes an HttpRequest Class that works as a lower layer than the SOAP APIs. You should be able to write up a test method that sends a hard-coded XML request to the server and dumps the HttpResponse so you can see it.
Adding my own best answer, based on some internet research:
You can use an external tool like Runscope as a webservice proxy to automatically forward requests and pass through responses and view the XML SOAP messages. This is not a native solution on SFDC but it does do the job.
https://www.runscope.com/
The issue is that Force.com is trying to parse a SOAP response that's actually just HTML. This happens sometimes when an error occurred server-side and the response is meant for a browser to display, rather than sending back an exception report via a properly formatted SOAP response.
If they can't figure out why they are not sending back a consumable SOAP response, then you can try using other tools (outside of Force.com) to make the same webservice call from your browser and then see what the HTML actually says on return.
We have a problem with HTTP Response caching when using WCF RIA Services with Silverlight.
Server side, we have a simple DomainService GET method with no caching specified, like this:
[OutputCache(OutputCacheLocation.None)]
public IQueryable<SearchResults> GetSearchResults(string searchText);
The throws a DomainException when the user is not authenticated (i.e. when the FormsAuthenticationCookie expires). This is as designed.
But when the user is re-authenticated, and the Query is called again with the same 'searchText' parameter, then the Query never gets to the server (no breakpoint hit; Fiddler shows no http request sent).
I think this is because when the exception is thrown on the server, the HTTP Response has the 'Cache-Control' property set to 'private', and when the client wants to perform the same query later (once the user is logged in), then the browser does not even send the request to the server.
If we enter a different search parameter, then the query is re-executed no problem.
Is there any way of ensuring the http response always has 'no-caching' - even when it does not return normally?
UPDATE1
The problem only occurs when deployed to IIS - when testing from Visual Studio with either Casini or IIS Express it works fine.
UPDATE2
I updated the question to reflect new knowledge.
You shouldn't be throwing a DomainException for authorization errors. Due to the way Silverlight handles faults, these responses can still be cached by your browser. Instead, throw an UnauthorizedAccessException from your DomainService and that should fix the caching error on the client.
I have a Silverlight 4 app that is hosted in an ASP Azure web role. The web role exposes a WCF service. (All this is in the same Visual Studio solution.)
I successfully added a reference to the service, and generated client code. However, it causes an error:
ExpenseServiceClient service = new ExpenseServiceClient();
service.GetExpensesCompleted += new EventHandler<GetExpensesCompletedEventArgs>(service_GetExpensesCompleted);
service.GetExpensesAsync();
The callback:
static void service_GetExpensesCompleted(object sender, GetExpensesCompletedEventArgs e)
{
if (e.Error != null)
{
MessageBox.Show(e.Error.ToString());
return;
}
// ...
}
e.Error is the following:
{System.ServiceModel.CommunicationException:
An error occurred while trying to make
a request to URI
'http://localhost:88/ExpenseService.svc'.
This could be due to attempting to
access a service in a cross-domain way
without a proper cross-domain policy
in place, or a policy that is
unsuitable for SOAP services. You may
need to contact the owner of the
service to publish a cross-domain
policy file and to ensure it allows
SOAP-related HTTP headers to be sent.
This error may also be caused by using
internal types in the web service
proxy without using the
InternalsVisibleToAttribute attribute.
Please see the inner exception for
more details.
---> System.Security.SecurityException --->
System.Security.SecurityException: Security error.
at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
at System.Net.Browser.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)
--- End of inner exception stack trace ---
at System.Net.Browser.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
at System.Net.Browser.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)
--- End of inner exception stack trace ---
at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)
at ExpenseCalc_SilverLight.ExpenseService.ExpenseServiceClient.ExpenseServiceClientChannel.EndGetExpenses(IAsyncResult result)
at ExpenseCalc_SilverLight.ExpenseService.ExpenseServiceClient.ExpenseCalc_SilverLight.ExpenseService.IExpenseService.EndGetExpenses(IAsyncResult result)
at ExpenseCalc_SilverLight.ExpenseService.ExpenseServiceClient.OnEndGetExpenses(IAsyncResult result)
at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)} System.Exception {System.ServiceModel.CommunicationException}
Both of these are running on localhost. What am I doing wrong?
Silverlight expects a ClientAccessPolicy.XML file to be present whenever it makes calls that in considers to be "cross domain" (worded that way b/c its fairly strict). Have you set that up? I'm not a SL expert, but that error normally arises when the policy file is not present.
Easy way is to create one at root of your site, so http://localhost/clientaccesspolicy.xml
A pretty loose "allow all" file is something like:
<?xml version=""1.0"" encoding=""utf-8""?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers=""*"">
<domain uri=""*""/>
</allow-from>
<grant-to>
<resource path=""/"" include-subpaths=""true""/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
For more complex scenarios (as may arise in Azure, depending on your architecture), you can create an IIS handler to serve up the expected XML, which allows for dynamic creation of the policy based on the request.
There are plenty of resources on this approach should you decide to go for it, but I'd recommend trying to simple one first to make sure that's the issue.
I don't know much about SilverLight, but I've come across mention of cross domain policies when talking about deploying SilverLight apps that use Azure storage. My Google foo is weak, but you might try one of these links.