I would like to pass a date string to a web service for testing, using a browser. I've tried Chrome and Firefox and both error out with this:
Server Error in '/' Application.
A potentially dangerous Request.Path value was detected from the client (:
The web service (RESTful) is accessed like this:
http://localhost:52936/Accounts/mod_date/2015-05-13T15%3A15%3A19
I've tried enclosing the date in quotes, but get the same error. Is this possible?
Try a QueryString Parameter
Since you are just performing testing, you should be able to pass your stringified DateTime value as a querystring parameter and it should avoid your service throwing a fit :
/Accounts/mod_date?yourDateParameterName=2015-05-13T15:15:19
Or if you wanted a more in-depth approach, you could consider using a suggestion like the one mentioned in this related discussion.
Explicitly Allow : Characters
Scott Hanselman covers the idea of explicitly allowing certain characters to be passed to a service via a URL in this blog post. It basically allows you to define which values are considered "dangerous" when passed in and would simply involve you changing the requestPathInvalidCharacters setting within the web.config of your application from :
<httpruntime requestvalidationmode="2.0">
requestPathInvalidCharacters="<,>,*,%,:,&,\"
/>
</httpruntime>
to :
<!-- Removes the colon ':' as a dangerous parameter -->
<httpruntime requestvalidationmode="2.0">
requestPathInvalidCharacters="<,>,*,%,&,\"
/>
</httpruntime>
This is obviously very controversial stuff and may not be useful for all scenarios, but it is an option.
Consider Postman (for Testing)
Additionally for testing purposes, you might consider using a service like Postman, which is ideal for performing this type of API testing.
Related
My application uses versions 2.19.0 of camel-core and camel-spring-ws. I need it to send a response message to a Client's service using Camel's SpringWebserviceComponent.
It's all pretty standard apart from the client's url, it contains a parameter at the end with no value e.g. https://client-service.com/path/index.php?protocol+web_service
I have never seen a URL like this before but the client states that the parameter on the end (after the question mark and with no value) maps to a controller in their application.
When I try to feed this into my application, I get a org.apache.camel.ResolveEndpointFailedException.
I've looked through the source code of the SpringWebserviceComponent and line 129 of org.apache.camel.impl.DefaultComponent (of which SpringWebServiceComponent extends) validates the URL parameters and throws the ResolveEndpointFailedException if any of the parameters are not valid parameters for the Spring web service component, as listed here: https://camel.apache.org/spring-web-services.html. Ofcourse, protocol+web_service is not a valid parameter for the SpringWebserviceComponent and so the exception is thrown.
This validation is only conducted if the SpringWebServiceEndpoint's isLenientProperties() method returns false, which it is hard-coded to do.
Can anyone suggest any other ways to make the SpringWebServiceComponent accept this url including its non-standard parameter?
Sorry this is not support out of the box, you can try to extend the spring-ws component and override some of the methods that setup the endpoint and whatnot, and then add your hack for this "invalid" url that your client uses.
Does anyone know if its possible to invoke a fuseaction within a coldfusion template?
(You haven't specified which Fusebox version; this answer applies to Fusebox 5.x)
Your title and question is asking two different things - a fuse and a fuseaction are two distinct things. A fuse is simply a CFML template, whilst a fuseaction represents a bundle of logic that performs a particular action (similar to a function).
Fuses:
To invoke a fuse, simply include the file as you would normally - there's no special FB functionality required for this.
Fuseactions:
To invoke a fuseaction, use the do verb, like so:
<cfset myFusebox.do('circuit.fuseaction') />
To store the result, use the second argument for the content variable:
<cfset myFusebox.do('circuit.fuseaction',varname) />
This is the equivalent of this XML:
<do action="circuit.fuseaction" contentvariable="varname" />
There are other arguments available, see this Fusebox cheat sheet which contains plenty of other useful info too.
With MVC, you should be working through a single entry-point. So only a single fuseaction should be called during your request.
BUT that fuseaction can call some of the other model and view templates as needed. And I believe that Fusebox allows you to refactor that logic into something that can be used by multiple actions. (I'm a bit rusty on my Fusebox functionality though, but I bet some Googling will lead you the way.)
As a dire last resort, you could use <cfhttp> to call a URL within your app that invokes that fuseaction. But why not just run some of the code directly without needing to burden your server with another HTTP call?
I've been trying to programmatically reproduce the behavior of editing a Content Type's field properties in the SharePoint site management screen and selecting the "Required" radio button with no sucess using the WSS 3.0 web service's Webs.asmx "UpdateContentType" method.
The first difficulty was the issue with the MSDN documentation that said fields should be of a FieldRef type when in fact they need to be of a Field type (reference). Adding fields and deleting fields works fine after the fix, but updating fields seems to not function at all. (It should also be noted that I followed the recommendation on the previous link to use Method="2" for updating fields but it changes nothing, and using Method values other than 1 for adding or other than 3 for deleting also function correctly).
Here's the web service call (slightly modified with strings instead of XmlNode objects for readability):
SharePointWebServices.Webs webService = new SharePointWebServices.Webs();
webService.Url = "http://mysharepointserver/site";
webService.UseDefaultCredentials = true;
webService.UpdateContentType(
#"0x01005A089D9EC8A382458FB1F6C72096D52A",
#"<ContentType />",
#"<Fields />",
#"<Fields><Method ID=""1""><Field Name=""SomeField"" ID=""{8a4803c4-6545-4a7a-804d-237eebff0ce3}"" Required=""TRUE"" Hidden=""FALSE"" ReadOnly=""FALSE"" PITarget="""" PIAttribute="""" PrimaryPIAttribute="""" Aggregation="""" Node="""" /></Method></Fields>",
#"<Fields />");
After the call, the field is still Required="FALSE".
A quick look into the stssoap.dll assembly indicates that the "Required" property is apparently ignored during the update process. Is this normal behavior? If so, what is the recommended method for programmatically changing the "Required" field from client code (not executing on the SharePoint server)?
Any help would be greatly appreciated.
I've investigated this and found the same thing. I also tried adding the attribute Cmd="Update" to the Method element without success. This example of how to use UpdateContentType was helpful too.
I don't believe you will be able to do this with the out-of-the-box SharePoint services. You've verified from looking at stssoap.dll that this doesn't appear to work correctly. Another 'client'-style option is to use RPC methods but none appear to provide functionality for content types at all.
The web services are particularly frustrating because this type of not-so-edge case regularly comes up. It is very rare that I consider using them because of the time wasting involved with their limitations.
Do you have any option of deploying custom code to the server? You could develop this functionality using the object model and wrap it in your own custom web service (there is a walkthrough here) quite easily.
Here is an example adapted from Gabe Wishnie that does what you require:
SPContentType myContentType = myWeb.ContentTypes["myContentType"];
string internalName = myContentType.Fields["fieldToUpdate"].InternalName;
myContentType.FieldLinks[internalName].Required = false;
myContentType.Update(true);
Sorry this isn't more helpful but it's a common story when using the WSS 3.0 / SharePoint 2007 web services.
I have a resource at a URL that both humans and machines should be able to read:
http://example.com/foo-collection/foo001
What is the best way to distinguish between human browsers and machines, and return either HTML or a domain-specific XML response?
(1) The Accept type field in the request?
(2) An additional bit of URL? eg:
http://example.com/foo-collection/foo001 -> returns HTML
http://example.com/foo-collection/foo001?xml -> returns, er, XML
I do not wish to oblige machines reading the resource to parse HTML (or XHTML for that matter). Machines like the googlebot should receive the HTML response.
It is reasonable to assume I control the machine readers.
If this is under your control, rather than adding a query parameter why not add a file extension:
http://example.com/foo-collection/foo001.html - return HTML
http://example.com/foo-collection/foo001.xml - return XML
Apart from anything else, that means if someone fetches it with wget or saves it from their browser, it'll have an appropriate filename without any fuss.
My preference is to make it a first-class part of the URI. This is debatable, since there are -- in a sense -- multiple URI's for the same resource. And is "format" really part of the URI?
http://example.com/foo-collection/html/foo001
http://example.com/foo-collection/xml/foo001
These are very easy deal with in a web framework that has URI parsing to direct the request to the proper application.
If this is indeed the same resource with two different representations, the HTTP invites you to use the Accept-header as you suggest. This is probably a very reliable way to distinguish between the two different scenarios. You can be plenty sure that user agents (including search engine spiders) send the Accept-header properly.
About the machine agents you are going to give XML; are they under your control? In that case you can be doubly sure that Accept will work. If they do not set this header properly, you can give XML as default. User agents DO set the header properly.
I would try to use the Accept heder for this, because this is exactly what the Accept header is there for.
The problem with having two different URLs is that is is not automatically apparent that these two represent the same underlying resource. This can be bad if a user finds an URL in one program, which renders HTML, and pastes it in the other, which needs XML. At this point a smart user could probably change the URL appropriately, but this is just a source of error that you don't need.
I would say adding a Query String parameter is your best bet. The only way to automatically detect whether your client is a browser(human) or application would be to read the User-Agent string from the HTTP Request. But this is easily set by any application to mimic a browser, you're not guaranteed that this is going to work.
My dilemma is, basically, how to share an enumeration between two applications.
The users upload documents through a front-end application that is on the web. This application calls a web service of the back-end application and passes the document to it. The back-end app saves the document and inserts a row in the Document table.
The document type (7 possible document types: Invoice, Contract etc.) is passed as a parameter to the web service's UploadDocument method. The question is, what should the type (and possible values) of this parameter be?
Since you need to hardcode these values in both applications, I think it is O.K. to use a descriptive string (Invoice, Contract, WorkOrder, SignedWorkOrder).
Is it maybe a better approach to create a DocumentTypes enumeration in the first application, and to reproduce it also in the second application, and then pass the corresponding integer value to the web service between them?
I'd suggest against passing an integer between them, simply for purposes of readability and debugging. Say you're going through your logs and you see a bunch of 500 errors for DocumentType=4. Now you've got to go look up which DocumentType is 4. Or if one of the applications refers to a number that doesn't exist in the other, perhaps due to mismatched versions.
It's a bit more code, and it rubs the static typing part of the brain a bit raw, but in protocols on top of HTTP the received wisdom is to side with legible strings over opaque enumerations.
I would still use enumeration internally but would expect consumers to pass me only the name, not the numeric value itself.
just some silly example to illustrate:
public enum DocumentType
{
Invoice,
Contract,
WorkOrder,
SignedWorkOrder
}
[WebMethod]
public void UploadDocument(string type, byte[] data)
{
DocumentType docType = (DocumentType)Enum.Parse(typeof(DocumentType), type);
}
I can only speak about .net, but if you have an ASP.net Webservice, you should be able to add an enumeration directly to it.
When you then use the "Add Web Reference" in your Client Application, the resulting Class should include that enum
But this is from the top of my head, i'm pretty sure i've done it in the past, but I can't say for sure.
In .NET, enumeration values are (by default) serialized into xml with the name. For instances where you can have multiple values (flags), then it puts a space between the values. This works because the enumeration doesn't contain spaces, so you can get the value again by splitting the string (ie. "Invoice Contract SignedWorkOrder", using lubos's example).
You can control the serialization of values of in asp.net web services using the XmlEnumAttribute, or using the EnumMember attribute when using WCF.
If you are consuming your Web service from a .NET page/application, you should be able to access the enumeration after you add your Web reference to the project that is consuming the service.
If you are not working with .NET to .NET SOAP, you can still define an enumerator provided both endpoints are using WSDL.
<s:simpleType name="MyEnum">
<s:restriction base="s:string">
<s:enumeration value="Wow"/>
<s:enumeration value="This"/>
<s:enumeration value="Is"/>
<s:enumeration value="Really"/>
<s:enumeration value="Simple"/>
</s:restriction>
</s:simpleType>
Its up to the WSDL -> Proxy generator tool to parse that into a enum equivalent in the client language.
There are some fairly good reasons for not using enums on an interface boundary like that. Consider Dare's post on the subject.
I've noticed that when using "Add Service Reference" as opposed to "Add Web Reference" from VS.net, the actual enum values come across as well as the enum names. This is really annoying as I need to support both 2.0 and 3.5 clients. I end up having to go into the 2.0 generated web service proxy code and manually adding the enum values every time I make a change!