We are exposing swagger-ui from our webserver using the Swashbuckle package working on top of Asp.Net Core. We are hitting an input validation issue for our Guid input fields.
The GUIDs we are pasting in, which are read from other parts of the system, are formatted as deb83f8a3edc4b78a2ece3321f81b58b, note the missing dashes. The input validation rejects this as it expects dashes in the format (so it accepts deb83f8a-3edc-4b78-a2ec-e3321f81b58b).
The swagger document that we serve has the parameter as type: string and format: uuid. It calls to some internal validationGuid call that have a reg-ex that forces the dashes. From the browser Console it seems like it is looking for a component called JsonSchema_string_uuid but is not finding it.
So my question is how can I extend swagger-ui to override the validation of specific parameter type/formats?
UPDATE:
I was made aware of the RFC that specifies a UUID as containing dashes and a workaround. However, I'm still interested in learning about ways to customize the validation of both custom formats and specifically uuid?
While the OpenAPI Specification and JSON Schema do not currently define format: uuid, RFC 4122 defines UUID as containing dashes, and some comments in the OpenAPI repository suggest that format: uuid is supposed to follow RFC 4122. This means your example without dashes is most likely not format: uuid.
Consider replacing format: uuid with pattern: '^[A-Fa-f0-9]{32}$'.
Related
I have this code:
#PostMapping("foobar")
public ResponseEntity<SaveLogsResult> foobar(#RequestPart("file") MultipartFile log, #RequestPart("env") MultipartFile json){
return ResponseEntity.ok(fooService.saveFooBar(log, json, UUID.randomUUID().toString()));
}
Two applications send formally correct data to this endpoint, one fails miserably and receives an http status 400.
I set logging.level.org.springframework.web=DEBUG and can see (among other lines) this:
Required request part 'env' is not present
Resolved [org.springframework.web.multipart.support.MissingServletRequestPartException: Required request part 'env' is not present]
Completed 400 BAD_REQUEST
To further diagnose this I compared a working (left) and a non-working (right) request. The only different is the mising filename:
As far as I understand the RFC for Content-Disposition leaving out the filename is perfectly valid:
Is followed by a string containing the original name of the file
transmitted. The filename is always optional and must not be used
blindly by the application: path information should be stripped, and
conversion to the server file system rules should be done. This
parameter provides mostly indicative information. When used in
combination with Content-Disposition: attachment, it is used as the
default filename for an eventual "Save As" dialog presented to the
user.
Is this an error inside Spring ? I use Spring Boot 2.6.2
Unfortunately I can't change the non-working component for a quick test because it is a bought component that doesn't receive bugfixes very often.
I think that my problem is different from that described here because the failure only happens in a specific scenario.
It looks like you have to provide the filename. see this issue
This [The situation in which filename is not present] can lead to inconsistencies, e.g. you would get it with
MultipartFile but not with collection or array of MultipartFile, and
one can make the opposite argument that it should be rejected.
Why does it matter to have it injected as MultipartFile if it doesn't
even have a filename? You could also inject it as InputStream or any
other type supported by a registered HttpMessageConverter.
I am using spring-security-saml2 1.0.0.RELEASE.
It works well and pretty good for me.
But New requirement is rised. I need saml-token as string.
can I get the saml-token as string. I find saml-token in log.
But how to get the saml-token as string format?
Good question, I've just added a new chapter to the Spring SAML manual which addresses this issue:
Authentication assertion
Assertion used to authenticate user is stored in the
SAMLCredential object under property authenticationAssertion. By
default the original content (DOM) of the assertion is discarded and
system only keeps an unmarshalled version which might slightly differ
from the original, e.g. in white-spaces. In order to instruct Spring
SAML to keep the assertion in the original form (keep its DOM) set
property releaseDOM to false on bean WebSSOProfileConsumerImpl.
Assertion can be serialized to String using the following call:
XMLHelper.nodeToString(SAMLUtil.marshallMessage(credential.getAuthenticationAssertion()))
I've been using Angular UI Router with a current project and have introduced some compound form inputs that I'd like to use as parameters in URL building for my routes. Essentially, the models I would like to parameterize are object literals, and I'm curious to know if ui-router has any ability to represent these as URL parameters.
In other parts of our application we have represented compound parameters with dot notation, e.g. ?field1.a=&field1.b=&field1.c, and I know some PHP frameworks make use of an array notation, e.g. ?field1[a]=field1[b]=field1[c] for representing multiple form fields associated with a single model.
From what I can tell, angular ui-router doesn't support similar. We are using v0.2.8, and at ~L131 there is a normalization function that will coerce object literals to their [object Object] string representation. It is this value that appears in URLs built with this kind of parameter, e.g. ?field1=[object Object].
I have considered lumping all the relevant fields together as a single parameter with a JSON string value as a workaround, e.g. ?filter={"field1":{}, "field2":{}, ...}, but wanted to check in to see if anyone has a better solution.
Thanks!
You have good timing. Typed parameter support was just merged into ui-router master. It isn't part of the 0.2.10 release, but should be part of 0.3.0 release, which is a few weeks away. If you build your own copy of bleeding-edge master and use this functionality now, please submit feedback to the ui-router project!
Here's the pull request that got merged with typed parameter support: https://github.com/angular-ui/ui-router/pull/1032
Read the docs regarding Type in https://github.com/angular-ui/ui-router/blob/master/src/urlMatcherFactory.js#L583
since i'm using something like http://mywebsite.web/{nickname}/dostuff i was wondering if there's a standard validation for the "nickname" string so that it won't contain reserved characters and stuff like that
I haven't come across any such functionality in Restlet, but what you could do is to get the value of {nickname} in your resource that is handling that URL, and validate it with a regular expression.
I made a Spring REST application where you can perform CRUD operations based on HTTP methods of POST, PUT, GET, DELETE. I have the typical URI template of
http://host/root/{id}/{name}/{address} and etc.
We have a client who is accessing this REST service. Apparently they are sending parameters for multi-word name and address in the following form:
http://host/root/11/John+Smith/10+Las+Vegas+USA
They are using the HTML encoding scheme based on application/x-www-form-urlencoded type. According to the article in Wikipedia
The application/x-www-form-urlencoded
type
The encoding used by default is based
on a very early version of the general
URI percent-encoding rules, with a
number of modifications such as
newline normalization and replacing
spaces with "+" instead of "%20". -
http://en.wikipedia.org/wiki/Percent-encoding
However it appears the standard URL encoding scheme is to use %20 in replacing spaces in URI templates. Which one is correct?
My Spring REST automatically converts %20 to spaces. It's interpreted correctly. I'm using Spring 3.0.4. When + is met by my REST service, it's accepted as is. Of course when I put validation to exclude +, it is indeed excluded as expected.
Am I within standards or are there such double standards? Or is the client using an ancient scheme?
The point is that application/x-www-form-urlencoded can be used only in request parameters, whereas percent encoding is also supported in a path.
So,
http://host/root/11/?name=John+Smith&address=10+Las+Vegas+USA
is fine and will be properly decoded by Spring MVC, but
http://host/root/11/John+Smith/10+Las+Vegas+USA
is wrong and Spring MVC doesn't decode it, because the following form should be used instead:
http://host/root/11/John%20Smith/10%20Las%20Vegas%20USA