In my web api I allow the user to specify how they want their data via an extension: ie. host/api/location/getmyhouse.json or getmyhouse.xml.
However I also have actions that aren't get and they return if the action was successful or not. For that it doesn't really make sense to specify the return type so I was trying to have it just default to json. However by default it seems xml is used.
Is there a way to default the formatter to json vs xml without removing xml as a formatter AND without having the client specify it as I want this to be done via simple url in the browser. It's an internal thing so that's what we would like.
Related
I have an Azure Mobile service with a .Net back end.
In the backend the data object use proper case. for example, MemberNumber.
In the azure client the view models use pascal case memberNumber.
I am using a library that creates an ODATA request and I get:
The query specified in the URI is not valid. Could not find a property named 'memberNumber' on type 'arenaapi.DataObjects.Members'.
That happens with this get:
/tables/members?%24inlinecount=allpages&%24orderby=memberNumber
If I change that the MemberNumber it works.
However, also, if I change the request to:
/tables/members?%24inlinecount=allpages&$orderby=memberNumber
It also works. It seems that the model binding parser is working differently if the $ is encoded or not.
Is there any way I can fix this server side so the encoded request won't return a 400 without changing the memberNumber to MemberNumber?
All the other stuff, posting, patching, etc is properly binding the pascal cased JSON post to proper cased c# data objects.
my Firefox addon shall add a search engine, that
provides suggestions
gets its search template URL specified on runtime (i.e.: template URL depends on the preferences of the user)
And I don't see a way to do both at the same time.
I see two options to add a search engine:
addEngineWithDetails
addEngine
addEngineWithDetails() allows me to add a search engine with the template URL. But it does (apparently?) not allow to provide a suggestions URL.
addEngine() allows me to add a search engine that is specified in an XML file. But if have that file saved locally in my addon directory (e.g. chrome://example-engine/content/search.xml), how can I change the template URL on runtime? And using an online XML is an unsafe options since the internet connection could be broken or bad during the addon install.
First fo all, you're right, addEngineWithDetails does not support suggestions.
The way to go would be to use addEngine (and removeEngine).
As for the "dynamic" part of your question: While I didn't test it, the implementation seems to happily accept data: URIs. So you could:
Construct a data URI using whatever methods you like (even constructing a full XML DOM and serializing it).
Call addEngine with the data URI.
When the user changes a pref, remove the old engine, and construct a new one.
I am trying to work out a way to provide a CSV download through a Spring 3 Portlet. I have a method that uses the #ResourceMapping annotation to define a handler that takes some report params in the form of a #ModelAttribute, builds the report, and returns it. The catch-22 I am running into is validating the parameters being send in from the client form.
If I make the handler a #ResourceMapping, I can set the headers and write out the report as using the ResourceResponse, but I can't seem to figure out how to redirect the user back to the Portlet view with errors when their input fails validation. However, if I make it an #ActionMapping, I can then check the BindingResults and forward them back to the form as needed, but the ActionResponse doesn't allow me to set the Content-Disposition header nor write out the CSV bytes, which is sort of critical for sending the report back.
I am at a total loss here, as I don't even know what my options are. Is it even possible to do what I am trying to do with a Portlet? Are there other examples I could look at for a possible work-around?
I suggest you to use both #ActionMapping and #ResourceMapping to fulfill your requirement.
As you said you were able to handle the validation errors using the #ActionResponse, I'll tell you how to handle the Resource Streaming.
As you know every #ActionResponse is followed by a #RenderResponse, just return the same view but, with a hidden iframe this time whose src points to the ResourceURL.
Now the Request you receive in #ResourceMapping is something which is already Validated. So, you can now serve your CSV.
I dont know how complex is your UI and if you are using jsp as views in your application. If nicely managed, Validation can be handled by #ResourceMapping.
Thank you
Is there any built-in support for validating malicious input within the Web API, similar to forms with MVC?
If not, could anyone suggest a "global" filter/message inpector/whatever to validate against malicious input? I'm trying to avoid validating all of my models/parameters individually...
No, I don't believe there is such support. Here's why. The input validation support with Web Forms/MVC was a stopgap measure. But encoding output is the better XSS fix; validating input doesn't work perfectly, as what input is "bad" depends on how you'll be outputting it (as part of HTML element source, as part of JS source, in an HTML attribute value, as part of a SQL query, etc.).
So I'd recommend against generic, global input validation as the solution to XSS concerns. Instead, make sure you're always encoding input correctly before outputting it (or passing it on to another layer, such as a SQL DB). For output, if you're using the normal Web API mechanisms for returning data (model classes with content negotiation/formatters), the formatters should handle the content type-specific encoding for you.
I believe XSS is not relevant to ASP.NET Web API. Here is why I think so. Suppose, in the request body, say I get a JSON like this "input": "<script>alert('hello');</script>" and the web API stores the "input" which is bound to some property as-is into a database and retrieve it as-is in a subsequent GET request and sends that off to a client, it is still okay. It is the responsibility of the client to ensure this data is escaped correctly. So, when this input property is serialized to say a web application, before it writes to the browser, the client web app must HTML encode. Web API doing this generally does not make sense because a web API can be consumed by other clients say a WPF application where XSS may not be applicable. Or am I missing any specific case you have in mind?
Why dont you use HttpUtility.HtmlEncode?
Input should always be validated. It doesn't matter where it is going. A name field should return a name string, not a jpeg file or for example depending on your environment a SQL attack.
I am trying to parse through the contents of an xml file resident on a remote server in visual basic 6.0 using the MSXML2.DOMDocument class.
I am using the Load method of the MSXML2.DOMDocument class to pass in the url. The url is of the form http://<server>/ABC.xml, however, the server requires user credentials for accessing the file.
How do I pass in user credentials using this class or another supporting class?
You can use http://<username>:<password>#<server>/ABC.xml in many cases, or you can use the XMLHTTPRequest helper object to make the actual requests.
Note that when you use an MSXML DOMDocument object you aren't parsing anything, the object does the heavy lifting. All you're doing is navigating the DOM tree, a trivial task by comparison.