What is the difference between attributes such as [RequireRole("admin")] and [ValidateHasRole("admin")]?
https://docs.servicestack.net/authentication-and-authorization#requiredrole-and-requiredpermission-attributes
https://docs.servicestack.net/declarative-validation#type-validators
It does say in the docs:
ServiceStack includes built-in Type Validator attributes for all Authorization Filter Attributes but as they’re decoupled from any implementation they can be safely annotated on Request DTOs without requiring any implementation dependencies.
Which dependencies are those? As I understand, [RequireRole("admin")] can be put on the service or directly on the DTO.
The [RequireRole] is implemented by the RequiredRoleAttribute.cs Request Filter Attribute in ServiceStack.dll.
Your ServiceModel project containing your API DTOs should not have any concrete implementation assemblies like ServiceStack.dll so if you want to annotate your Request DTOs with Authentication attributes you should use the declarative fluent validation [Vaidate*] instead which exists in the impl-free ServiceStack.Interfaces.dll - i.e. the only ServiceStack .dll your Service Models (DTOs) should reference.
Related
ServiceStack has support for OpenAPI and can generate an OpenAPI spec. However, for APIs/endpoints to be generated in the spec, it is not enough to specify the API details using the Route attributes as described here, you also need to create the Service classes that (eventually) implement the functionality.
Is there a way to make the OpenAPI specification include everything without having to create the Service classes that go with them?
The reason is that sometimes you just want to work on the specification, not implementation (even though you can just skip implementation details and throw a NotImplementedException), and creating those Service classes just to get the spec to show is annoying.
If it doesn't have an implementation it's not a Service and therefore wont have any of ServiceStack's metadata or features available for it.
If you want to skip their implementation you can just create stub implementations for them, e.g:
public class MyServices : Service
{
public object Any(MyRequest1 request) => null;
public object Any(MyRequest2 request) => null;
public object Any(MyRequest3 request) => null;
}
I am writing a NestJS service that provides a REST API and it publishes some messages to NATS. We are using the NestJS support to generate OpenAPI docs, and from the OpenAPI docs we generate an SDK that we import into our clients. This all works great, but only the REST API of our code is in the SDK.
What we'd like to also do is to have NestJS include the DTO's for the content for the messages we publish to NATS. Then our SDK will also include interfaces for these DTO's, and then our clients can cast the message content to the correct interface (based on the message subject). This way, the publisher of an event defines the content of the event, and users of it don't have to replicate the interface, yet they get strongly-typed code.
I've tried adding the #Api decorators to the DTO, but it appears that unless the DTO is used in the definition of an #Controller, it is not included in the resultant openApi docs.
I was hoping for a way to decorate a "random" DTO in my code so it will then be included in the swagger docs, and in-turn included in a generated SDK. Is something like that possible?
you can also pass extraModels array as a part of SwaggerDocumentOptions
SwaggerModule.createDocument(app, config, {
extraModels: [.......]
});
https://github.com/nestjs/swagger/issues/241
I just started learning NestJS and GraphQL. I started with a single resolver class UserResolver defined in UserModule. This class provides methods to read a list of users or a specific user. Methods are decorated with #Query(), a user.graphqlfile is provided, GraphQL is initialized in AppModule, all as described in the docs. All works well, I can get a list of users or specific user through Insomnia Tool or through Playground. I am happy!
Now I have created a second module, RoleModule. I created a role.graphql file and a RoleResolver class, I basically replicated all the work done for User but this time for Role. The GraphQL type definition for type Role as well as the Query definitions in the role.graphql file are recognized. What is not recognized are my Query() implementations in the RoleResolver class, they are not getting invoked.
If I put all these Role related #Query() definitions into the UserResolver class, these Role related queries are now getting invoked.
Is that expected behavior? Do I need to put all my GraphQL query definitions into a single class? Is it possible to spread NestJS-GraphQL resolver implementations over several modules? Am I doing something wrong? Please help.
Make sure that you import Query from #nestjs/graphql and not from #nestjs/common.
I'd like to define an interface on some of my servicestack service model request dto objects. I've defined the interface in my service model project and added it to the dto objects.
But in the client application when I use the "Update Service Stack Reference" function with the Visual Studio plugin, my interface definitions are not being added to my DTOs.
Previously the only interfaces included in the Add ServiceStack Reference feature are existing interfaces defined in the dep-free ServiceStack.Interfaces.dll to reduce coupling with external libraries but support for exporting (non-generic) implemented interfaces were just added from v4.5.13 which is now available on MyGet.
An alternative to having interfaces generated is including them in partial class that sits alongside the generated DTOs which define the interfaces you want each DTO to share, e.g:
public partial class MyDto : IMyInterface {}
The previous behavior of not exporting implemented interfaces can be reverted with:
var nativeTypes = this.GetPlugin<NativeTypesFeature>();
nativeTypes.MetadataTypesConfig.ExcludeImplementedInterfaces = true;
In Mule ESB I want to validate incoming SOAP/XML, using a standard Mule "schema-validation filter".
Something like:
<mulexml:schema-validation-filter schemaLocations="xxx.xsd" name="xxxValidationFilter"/>
However this kind of definition seem to assume that the schema is located in a separate xsd-file, whereas in a lot of cases the schema definition is embedded in the "wsdl:types" element of a wsdl-file.
Is there any way to use the Mule schema-validation-filter to validate against schema's which are embedded in the wsdl (except for copying the schema element definitions out of the
wsdl and into a separate xsd-file).
Mule service element tags which expose the service haave an attribute that can enable validation on the incoming request.
validationEnabled="true"
<cxf:simple-service validationEnabled="true"/>
<cxf:jaxws-service validationEnabled="true"/>
<cxf:proxy-service validationEnabled="true"/>
For more information refer to the following Mule documentation link.
http://www.mulesoft.org/documentation/display/current/Building+Web+Services+with+CXF
Hope this helps.