When developping several restx application (thus, working on localhost domain), restx cookies are interfering since their names are the same. Moreover, it would be nice to be able to change the RestxSession & RestxSessionSignature cookie names if the restx user doesn't want to tell its consumer that the serverside technology is based on restx.

Proposition here, is to define :

• An app.name @Named String, not set by default (to keep backward compatibility), allowing to suffix restx session cookie name with an app name. Thus, you will be able to work on different apps locally, which will have specific cookie names for the localhost domain name.
• A RestxSessionCookieDescriptor component, intended to welcome generated cookie names, @Provided by default in SecurityFactory with following values : -- RestxSession & RestxSessionSignature if app.name @Named String has not been defined (this will keep bacward compatibility) -- RestxSession-${app.name} & RestxSessionSignature-${app.name} is app.name @Named String has been defined Obviously, this behaviour can be overriden at the user convenience.

Note that if merged, you will need to update the Generated app explained documentation page, in order to talk about the app.name @Named String.

EDIT : Updated current pull request with another feature which was needed prior to the RestxSession cookie name generation : handling Optional injectable components. That is to say, if a @Provide method signature is looking like this :

@Provides
public Foo foo(Optional<Bar> bar) {
}

The Bar resolved component will be injected only if found. Otherwise, the Optional.absent() value will be provided. This will obviously work on @Named components too. Note that as soon as you're relying on an Optional component, you :

• Will need to provide a Generic to the Optional used (otherwise, you will have a compile-time error)
• Won't have any component existence check (since you explicitely said you're not hardly relying on the bar component)

We have a serious regression in released-but-not-announced-yet 0.35 version for RestX, regarding mongo id generation based on jongo

First of all, you will be encouraged by Jongo to make following steps :

• Replace deprecated @ObjectId annotation by @MongoObjectId
• Replace deprecated @Id annotation by @MongoObjectId @JsonProperty("_id") (@JsonProperty annotation being required only if your field as a different name than _id, for example you name it id)

Those migration steps are not impacting the regression (we encounter the regression both on "old" and "new" annotations)

I created a branch on my repository to spot this regression : tests on this branch are green on 0.34 and not on 0.35.

I identified 3 cases so far :

✅ Using @Id/@MongoId annotation AND ObjectId field type

Following syntax :

@MongoId @JsonProperty("_id")
private ObjectId id;

which corresponds to following legacy syntax :

@Id
private ObjectId id;

If you're in that case, then no regression will be impacting you

⛔️ Using @ObjectId @Id/@MongoId @MongoObjectId @JsonProperty("_id") annotations AND String field type

Following syntax is currently hitting one bug :

@MongoId @MongoObjectId @JsonProperty("_id")
private String id;

which corresponds to following legacy syntax :

@ObjectId @Id
private String id;

The detailed bug seems related to [email protected] incompatibility with [email protected] (see this jongo issue related to this bson4jackson issue) as we get following error :

ERROR restx.StdRestxMainRouter - request raised BsonSerializationException: While decoding a BSON document 4 bytes were required, but only 0 remain
org.bson.BsonSerializationException: While decoding a BSON document 4 bytes were required, but only 0 remain

ERROR restx.StdRestxMainRouter - request raised BsonSerializationException: While decoding a BSON document 4 bytes were required, but only 0 remain
org.bson.BsonSerializationException: While decoding a BSON document 4 bytes were required, but only 0 remain
	at org.bson.io.ByteBufferBsonInput.ensureAvailable(ByteBufferBsonInput.java:218) ~[mongo-java-driver-3.4.0.jar:na]
	at org.bson.io.ByteBufferBsonInput.readInt32(ByteBufferBsonInput.java:106) ~[mongo-java-driver-3.4.0.jar:na]
	at org.bson.BsonBinaryWriter.pipe(BsonBinaryWriter.java:304) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.DBEncoderAdapter.encode(DBEncoderAdapter.java:47) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.DBEncoderFactoryAdapter.encode(DBEncoderFactoryAdapter.java:33) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.DBEncoderFactoryAdapter.encode(DBEncoderFactoryAdapter.java:23) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.CompoundDBObjectCodec.encode(CompoundDBObjectCodec.java:48) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.CompoundDBObjectCodec.encode(CompoundDBObjectCodec.java:27) ~[mongo-java-driver-3.4.0.jar:na]
	at org.bson.codecs.BsonDocumentWrapperCodec.encode(BsonDocumentWrapperCodec.java:63) ~[mongo-java-driver-3.4.0.jar:na]
	at org.bson.codecs.BsonDocumentWrapperCodec.encode(BsonDocumentWrapperCodec.java:29) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.RequestMessage.addDocument(RequestMessage.java:253) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.RequestMessage.addCollectibleDocument(RequestMessage.java:219) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.InsertMessage.encodeMessageBodyWithMetadata(InsertMessage.java:73) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.RequestMessage.encodeWithMetadata(RequestMessage.java:160) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.WriteProtocol.execute(WriteProtocol.java:89) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.InsertProtocol.execute(InsertProtocol.java:68) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.InsertProtocol.execute(InsertProtocol.java:39) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.DefaultServer$DefaultServerProtocolExecutor.execute(DefaultServer.java:168) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.DefaultServerConnection.executeProtocol(DefaultServerConnection.java:289) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.connection.DefaultServerConnection.insert(DefaultServerConnection.java:76) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.operation.InsertOperation.executeProtocol(InsertOperation.java:66) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.operation.BaseWriteOperation$1.call(BaseWriteOperation.java:141) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.operation.BaseWriteOperation$1.call(BaseWriteOperation.java:133) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.operation.OperationHelper.withConnectionSource(OperationHelper.java:422) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.operation.OperationHelper.withConnection(OperationHelper.java:413) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.operation.BaseWriteOperation.execute(BaseWriteOperation.java:133) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.operation.BaseWriteOperation.execute(BaseWriteOperation.java:60) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.Mongo.execute(Mongo.java:845) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.Mongo$2.execute(Mongo.java:828) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.DBCollection.executeWriteOperation(DBCollection.java:342) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.DBCollection.insert(DBCollection.java:337) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.DBCollection.insert(DBCollection.java:328) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.DBCollection.insert(DBCollection.java:298) ~[mongo-java-driver-3.4.0.jar:na]
	at com.mongodb.DBCollection.insert(DBCollection.java:264) ~[mongo-java-driver-3.4.0.jar:na]
	at org.jongo.Insert.insert(Insert.java:59) ~[jongo-1.3.0.jar:na]
	at org.jongo.MongoCollection.insert(MongoCollection.java:140) ~[jongo-1.3.0.jar:na]
	at org.jongo.MongoCollection.insert(MongoCollection.java:132) ~[jongo-1.3.0.jar:na]
	at samplest.jongo.MongoResource.createObjectWithObjectIdAnnotation(MongoResource.java:75) ~[classes/:na]
	at samplest.jongo.MongoResourceRouter$2.doRoute(MongoResourceRouter.java:109) ~[classes/:na]
	at samplest.jongo.MongoResourceRouter$2.doRoute(MongoResourceRouter.java:104) ~[classes/:na]
	at restx.entity.StdEntityRoute.handle(StdEntityRoute.java:250) ~[classes/:na]
	at restx.RestxHandlerMatch.handle(RestxHandlerMatch.java:56) ~[classes/:na]
	at restx.ResponseCloserFilter.handle(ResponseCloserFilter.java:28) ~[classes/:na]
	at restx.RestxHandlerMatch.handle(RestxHandlerMatch.java:56) ~[classes/:na]
	at restx.CacheFilter$1.handle(CacheFilter.java:51) ~[classes/:na]
	at restx.RestxHandlerMatch.handle(RestxHandlerMatch.java:56) ~[classes/:na]
	at restx.security.RestxSessionLogFilter.handle(RestxSessionLogFilter.java:43) ~[classes/:na]
	at restx.RestxHandlerMatch.handle(RestxHandlerMatch.java:56) ~[classes/:na]
	at restx.security.RestxSessionCookieFilter.handle(RestxSessionCookieFilter.java:100) ~[classes/:na]
	at restx.RestxHandlerMatch.handle(RestxHandlerMatch.java:56) ~[classes/:na]
	at restx.StdRestxMainRouter.route(StdRestxMainRouter.java:153) ~[classes/:na]
	at restx.RestxMainRouterFactory$PerRequestFactoryLoader.route(RestxMainRouterFactory.java:233) [classes/:na]
	at restx.RestxMainRouterFactory$RecordingMainRouter.route(RestxMainRouterFactory.java:190) [classes/:na]
	at restx.servlet.AbstractRestxMainRouterServlet.service(AbstractRestxMainRouterServlet.java:48) [classes/:na]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) [javax.servlet-3.0.0.v201112011016.jar:na]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669) [jetty-servlet-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) [jetty-servlet-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [jetty-security-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382) [jetty-servlet-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.Server.handle(Server.java:365) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:937) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:998) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:856) [jetty-http-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240) [jetty-http-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) [jetty-server-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628) [jetty-io-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) [jetty-io-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) [jetty-util-8.1.8.v20121106.jar:8.1.8.v20121106]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) [jetty-util-8.1.8.v20121106.jar:8.1.8.v20121106]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]

⛔️ Using @Id/@MongoId @JsonProperty("_id") annotations AND String field type

Following syntax is currently hitting another bug :

@MongoId @JsonProperty("_id")
private String id;

which corresponds to following legacy syntax :

@Id
private String id;

In that case, the regression is id will be null after a call to JongoCollection.insert(). In 0.34 it was NOT null (id where populated).

The thing about this issue is it is completely "silent" (no error thrown), so you may not be aware of it if you migrate to 0.35 !

This issue seems related to [email protected] => [email protected] migration : https://github.com/bguerout/jongo/issues/325

This PR permits to manage several new things about cold classes.

• It permits to add inherited classes of cold components (components being loaded in the main factory, such as AutoStartable ones) in cold classes list.
• It adds a way to declare cold classes using a property: restx.cold.classes. The property value is a list of fqcn separated by :.
• It adds a way to declare cold classes using a resource file: META-INF/cold-classes.list. Resources will be loaded from the classloader, and every classes listed will be added to the cold classes list. The file must contains a list of fqcn, one per line.
• It provides a way to fulfil the resource file using an annotation: @Cold. So every classes annotated with @Cold will be added to the resource file (thanks to a new annotation processor).

This is a follow up for #62 I provided a new app archive command, allowing to generate a restx archive.

Some insight about the restx archive : the hello-world application generated from a restx app new will generate something like this :

$> tree
.
├── META-INF
│   ├── restx
│   │   └── app
│   │       ├── data
│   │       │   ├── credentials.json
│   │       │   └── users.json
│   │       ├── md.restx.json
│   │       ├── module.ivy
│   │       ├── pom.xml
│   │       └── src
│   │           ├── main
│   │           │   ├── java
│   │           │   │   └── helloworld
│   │           │   │       ├── AppModule.java
│   │           │   │       ├── AppServer.java
│   │           │   │       ├── Roles.java
│   │           │   │       ├── domain
│   │           │   │       │   └── Message.java
│   │           │   │       └── rest
│   │           │   │           └── HelloResource.java
│   │           │   ├── resources
│   │           │   │   └── logback.xml
│   │           │   └── webapp
│   │           │       └── WEB-INF
│   │           │           └── web.xml
│   │           └── test
│   │               ├── java
│   │               │   └── helloworld
│   │               │       └── rest
│   │               │           └── HelloResourceSpecTest.java
│   │               └── resources
│   │                   └── specs
│   │                       └── hello
│   │                           ├── should_admin_say_hello.spec.yaml
│   │                           ├── should_user1_say_hello.spec.yaml
│   │                           └── should_user2_not_say_hello.spec.yaml
│   └── services
│       └── restx.factory.FactoryMachine
├── helloworld
│   ├── AppModule.class
│   ├── AppModuleFactoryMachine$1.class
│   ├── AppModuleFactoryMachine$2.class
│   ├── AppModuleFactoryMachine$3.class
│   ├── AppModuleFactoryMachine$4.class
│   ├── AppModuleFactoryMachine$5.class
│   ├── AppModuleFactoryMachine.class
│   ├── AppServer.class
│   ├── Roles.class
│   ├── domain
│   │   └── Message.class
│   └── rest
│       ├── HelloResource.class
│       ├── HelloResourceFactoryMachine$1.class
│       ├── HelloResourceFactoryMachine.class
│       ├── HelloResourceRouter$1.class
│       ├── HelloResourceRouter.class
│       ├── HelloResourceRouterFactoryMachine$1.class
│       └── HelloResourceRouterFactoryMachine.class
└── logback.xml

ATM, I'm packaging sources files into the restx archive (because api doc might rely on it to display source contents) For the same reason, I package the src/test/* file hierarchy.

You can test it easily :

restx app new
................
restx app archive /tmp/hello.jar
................
restx app grab file:///tmp/hello.jar + app run

FYI, I just created a maven-restx-plugin which will re-use the RestxArchive.pack() utility method, in order to package a standard restx archive (with -restx classifier).

Important note : having the *.class files in the archive is totally useless since the first thing I do in app grab is to unzip & chroot to META-INF/restx/app/ directory (then, auto compile does the stuff for us).

This PR allows to define "variabilized" security roles based on what we have in query params or path param for a dedicated endpoint.

It will allow to typically have such endpoint checks :

    @GET("/security/{companyId}/{subCompanyId}")
    @RolesAllowed("EDIT_COMPANY_{companyId}_{subCompanyId}")
    public String editSubCompany(String companyId, String subCompanyId){
        // ....
    }

Changes have been made to StdRestxSecurityManager in order to generate a role interpolation map, basically with query & path parameters (but which may be overwritten with specific stuff if wanted on every project .. you'll only need to @Provide another StdRestxSecurityManager)

By introducing variabilized roles, I added a support for wildcards on roles located in RestxPrincipal That is to say, if current user has role named EDIT_COMPANY_1234_* he will be able to call every urls like /security/1234/* without having any 403 Forbidden response. The wildcard roles checks are generated at compilation time through RestxAnnotationProcessor (because variable cartesian product may take some time to generate, which we would like to avoid at runtime).

That is to say, corresponding generated code for endpoint above will be :

        new StdEntityRoute<Void, java.lang.String>("default#SecuredResource#editSubCompany",
                readerRegistry.<Void>build(Void.class, Optional.<String>absent()),
                writerRegistry.<java.lang.String>build(java.lang.String.class, Optional.<String>absent()),
                new StdRestxRequestMatcher("GET", "/security/{companyId}/{subCompanyId}"),
                HttpStatus.OK, RestxLogLevel.DEFAULT) {
            @Override
            protected Optional<java.lang.String> doRoute(RestxRequest request, RestxRequestMatch match, Void body) throws IOException {
                securityManager.check(request, match, anyOf(hasRole("EDIT_COMPANY_*_*"), hasRole("EDIT_COMPANY_*_{subCompanyId}"), hasRole("EDIT_COMPANY_{companyId}_*"), hasRole("EDIT_COMPANY_{companyId}_{subCompanyId}")));
                return Optional.of(resource.editSubCompany(
                        /* [PATH] companyId */ match.getPathParam("companyId"),
                        /* [PATH] subCompanyId */ match.getPathParam("subCompanyId")
                ));
            }
            // ....
`
``

Proposal to support bean validation groups during validation.

I'm not really satisfied by the current implementation and would like to open the discussion about it.

At first, I was planning to implement usage below :

    @PermitAll
    @POST("/valid/pojos")
    public void createPOJOWithoutAnnotation(POJO myPojo) { // No @ValidatedFor annotation => Default validation group will be implicitly used here, keeping backward compat behaviour
        LOG.info("Pojo {} {} created !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

    @PermitAll
    @POST("/valid/pojos2")
    public void createPOJOWithAnnotation(@ValidatedFor(FormValidations.Create.class) POJO myPojo) { // Here, defining we want to activate the Create validation group mode on validation
        LOG.info("Pojo {} {} created !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

    @PermitAll
    @PUT("/valid/pojos/{id}")
    public void createPOJOWithoutAnnotation(Long id, @ValidatedFor({MyCustomValidationGroup.class, FormValidations.Update.class}) POJO myPojo) { // Multiple validation groups can be provided, following bean validation's Validator API
        LOG.info("Pojo {} {} updated !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

with group declaration :

public interface FormValidations {
    public static interface Create extends Default{}
    public static interface Update extends Default{}
}

public class ValidationResource {
// ...
    public static interface MyCustomValidationGroup{}
// ...
}

But I faced some issues at annotation processing time when retrieving @ValidatedFor.value() classes : didn't completely understood why, but some classes (either in restx-core or in samplest) were not accessible. You can see some testing I made in commit 7f88a79573d00d5d28c796d238aaf0dfdde1fdcf (from branch validations-validatedfor-with-class, some github comments describe what's going weird)

Thus, I had to fallback from Class[] to String[] in order to directly provide validation group FQN used for source generation. Which makes declaration look like :

    @PermitAll
    @POST("/valid/pojos")
    public void createPOJOWithoutAnnotation(POJO myPojo) {
        LOG.info("Pojo {} {} created !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

    @PermitAll
    @POST("/valid/pojos2")
    public void createPOJOWithAnnotation(@ValidatedFor(FormValidations.CreateFQN) POJO myPojo) {
        LOG.info("Pojo {} {} created !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

    @PermitAll
    @PUT("/valid/pojos/{id}")
    public void createPOJOWithoutAnnotation(Long id, @ValidatedFor({MyCustomValidationGroupFQN, FormValidations.UpdateFQN}) POJO myPojo) {
        LOG.info("Pojo {} {} updated !", myPojo.getName(), myPojo.getSubPOJO().getLabel());
    }

and group declaration :

public interface FormValidations {
    public static final String DefaultFQN = "javax.validation.groups.Default";
    public static final String CreateFQN = "restx.validation.stereotypes.FormValidations.Create";
    public static interface Create extends Default{}
    public static final String UpdateFQN = "restx.validation.stereotypes.FormValidations.Update";
    public static interface Update extends Default{}
}

public class ValidationResource {
// ...
    public static interface MyCustomValidationGroup{}
    public static final String MyCustomValidationGroupFQN = "samplest.validation.ValidationResource.MyCustomValidationGroup";
// ...
}

If you see any workaround for this issue, I'm opened to discuss it.

Another way would be to rely on reflection but I know this is something we should avoid, especially for such trivial things.

Just executed following steps under Mac OS X :

$> rm -Rf ~/.restx/
$> sudo rm /usr/local/bin/restx
$> curl -s http://restx.io/install.sh | sh
Downloading RESTX 0.2.9.1 distribution
######################################################################## 100.0%

RESTX 0.2.9.1 has been installed in your home directory (~/.restx).
Writing a launcher script to /usr/local/bin/restx for your convenience.
This may prompt for your password.

RESTX is now properly installed, you can launch it using the restx command.

To get started, see the docs at:

  http://restx.io/docs/
$> restx
===============================================================================
== WELCOME TO RESTX SHELL - 0.2.9.1 - type `help` for help on available commands
===============================================================================
restx> shell install
:: loading settings :: url = jar:file:/Users/fcamblor/.restx/lib/restx-shell-0.2.9.1.jar!/restx/shell/ivysettings.xml
looking for plugins...
found 3 available plugins
 [  1] io.restx:restx-core-shell:0.2.9.1
        core commands: generate new app, ...
 [  2] io.restx:restx-build-shell:0.2.9.1
        build commands: generate pom, ivy, ...
 [  3] io.restx:restx-specs-shell:0.2.9.1
        specs commands: run a specs server, ...
Which plugin would you like to install (eg '1 3 5')?
You can also provide a plugin id in the form <groupId>:<moduleId>:<version>
 plugin to install: 1
installing io.restx:restx-core-shell:0.2.9.1...
installed io.restx:restx-core-shell:0.2.9.1
installed 1 plugins, restarting shell to take them into account
RESTARTING SHELL...

Exception in thread "main" java.util.ServiceConfigurationError: restx.factory.FactoryMachine: Provider restx.jackson.FrontObjectMapperFactoryFactoryMachine could not be instantiated: java.lang.NoClassDefFoundError: com/fasterxml/jackson/datatype/joda/JodaModule
    at java.util.ServiceLoader.fail(ServiceLoader.java:224)
    at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
    at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:370)
    at java.util.ServiceLoader$1.next(ServiceLoader.java:438)
    at com.google.common.collect.Iterators.addAll(Iterators.java:384)
    at com.google.common.collect.Iterables.addAll(Iterables.java:336)
    at com.google.common.collect.AbstractMultimap.putAll(AbstractMultimap.java:74)
    at com.google.common.collect.ArrayListMultimap.putAll(ArrayListMultimap.java:66)
    at restx.factory.Factory$Builder.addFromServiceLoader(Factory.java:103)
    at restx.shell.RestxShell.<init>(RestxShell.java:51)
    at restx.shell.RestxShell.main(RestxShell.java:317)
Caused by: java.lang.NoClassDefFoundError: com/fasterxml/jackson/datatype/joda/JodaModule
    at restx.jackson.FrontObjectMapperFactoryFactoryMachine.<clinit>(FrontObjectMapperFactoryFactoryMachine.java:10)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:362)
    ... 8 more
Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.datatype.joda.JodaModule
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    ... 12 more

When re-launching the shell, same error.

Seems like some dependencies are missing. I added them (com.fasterxml.jackson.datatype:jackson-datatype-joda:2.1.2, com.fasterxml.jackson.datatype:jackson-datatype-guava:2.1.2 and javax.validation:validation-api:1.1.0.Final) manually in the ~/.restx/lib/ folder and it solved the issue.

But later, during a restx app run, I encountered new errors :

$> restx app run
===============================================================================
== WELCOME TO RESTX SHELL - 0.2.9.1 - BATCH MODE
===============================================================================
> app run
compiling App... [DONE]
copying resources... [DONE]
starting com.crowdstore.AppServer... - type `stop` to stop it and go back to restx shell
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
    at com.crowdstore.AppServer.main(AppServer.java:20)
Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.Connector
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    ... 1 more

=> I gave up :)

Note that before adding manually the libs, I had :

$> ls ~/.restx/lib
compiler-0.8.11.jar             jackson-annotations-2.1.1.jar   javassist-3.16.1-GA.jar         logback-classic-1.0.11.jar      restx-factory-0.2.9.1.jar       xml-apis-1.0.b2.jar
dom4j-1.6.1.jar                 jackson-core-2.1.1.jar          javax.inject-1.jar              logback-core-1.0.11.jar         restx-shell-0.2.9.1.jar
guava-14.0.1.jar                jackson-databind-2.1.2.jar      jline-2.10.jar                  reflections-0.9.9-RC1.jar       restx-shell-manager-0.2.9.1.jar
ivy-2.3.0.jar                   jamon-2.7.jar                   joda-time-2.2.jar               restx-common-0.2.9.1.jar        slf4j-api-1.7.5.jar

Taking into account :

• The new app.name component (using the restx shell's appName property)
• Changing ordering of components, putting SignatureKey first, in order to follow documentation ordering on Generated app explained's AppModule section

During implementation, some new features appeared :

• Implementing a $RestxSession special header in restx specs files, allowing to define a restx session content (with proper cookie name, given available RestxCookieDescriptor component) and sign it with current SignatureKey component
• Improved HelloResource sample by providing a basic security implementation sample and using the @RolesAllowed annotation
• Provided a test harness in restx-core-shell allowing to validate that app new shell command generates a new app and this app has green tests

In windows, if a file is modified the default watch service is sending three events, one delete, one create and one modify. I will try to investigate in order to check if there is a solution for this, otherwise I think that we might solve this by creating a special event coalescor for windows, which will merge delete and create event for same files into a modify event.

It would be a good thing to allow to create some archive format dedicated to restx (for instance, *.restxar)

Requirements for this archive would be :

• To contain your project's class files
• Your project's dependencies descriptor (located in /META-INF/)
• Optionally your project's static resources Because of point 2, this restx archive should be really small (especially compared to a standard war which integrates every of its libraries)

Purpose of this archive would be to add the ability to the restx-shell to provision dependencies then start your project with provisionned classpath. I'm thinking about something like restx app run myproject.restxar which would :

• Read /META-INF/md.restx.json to gather dependencies coordinates
• Call ivy to download these dependencies
• Run the archive "as is" it was a jar, embedding it within a server (optionally, the server could be given as a parameter to the shell) and providing downloaded dependencies in the classpath

Hi there,

I was facing a strange issue with one of our app, let me explain what we're doing and what was causing this :

• we run job through quartz
• these jobs are using injection facilities provided by restx by creating a new factory then closing it when the job is done

When the app was running for quite a long time, we were facing OOME : can not start new native thread from com.mongodb.Mongo. By digging into the code I found out that new MongoClient() creates a new Thread (named MongoCleaner), the problem is that, when we close the factory, the mongoClient is not closed.

The actual fix (for this use case) consists in doing the following when closing the factory :

final MongoClient client = factory.getComponent(MongoClient.class);
if (client != null) {
    client.close();
}
factory.close();

Do you think it is a real issue and thus should be fixed by making MongoModule implementing / or returning a AutoCloseable to do this kind of cleanup ?

I can see that I'm able to getHeader(String), but I want to collect all x-* headers without knowing them in advance.

I'm able to use req.unwrap(Request.class) to get the text request headers and parse.

Just thought it would be nicer to have a getHeaders on the RestxRequest class.

Bumps jackson-databind from 2.10.1 to 2.12.6.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps snakeyaml from 1.25 to 1.31.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Security Vulnerability Fix

This pull request fixes a Zip Slip vulnerability either due to an insufficient, or missing guard when unzipping zip files.

Even if you deem, as the maintainer of this project, this is not necessarily fixing a security vulnerability, it is still, most likely, a valid security hardening.

Preamble

Impact

This issue allows a malicious zip file to potentially break out of the expected destination directory, writing contents into arbitrary locations on the file system. Overwriting certain files/directories could allow an attacker to achieve remote code execution on a target system by exploiting this vulnerability.

Why?

The best description of Zip-Slip can be found in the white paper published by Snyk: Zip Slip Vulnerability

But I had a guard in place, why wasn't it sufficient?

If the changes you see are a change to the guard, not the addition of a new guard, this is probably because this code contains a Zip-Slip vulnerability due to a partial path traversal vulnerability.

To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out"). The check is bypassed although /outnot is not under the /out directory. It's important to understand that the terminating slash may be removed when using various String representations of the File object. For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/; however, println(new File("/var", "/").getCanonicalPath()) will print /var.

The Fix

Implementing a guard comparing paths with the method java.nio.files.Path#startsWith will adequately protect against this vulnerability.

For example: file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY) or file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())

Other Examples

• CVE-2018-1002201 - zeroturnaround/zt-zip
• CVE-2018-1002202 - srikanth-lingala/zip4j
• CVE-2018-8009 - apache/hadoop

:arrow_right: Vulnerability Disclosure :arrow_left:

:wave: Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!

First question, do we need to perform vulnerability disclosure? It depends!

1. Is the vulnerable code only in tests or example code? No disclosure required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

For partial path traversal, consider if user-supplied input could ever flow to this logic. If user-supplied input could reach this conditional, it's insufficient and, as such, most likely a vulnerability.

Vulnerability Disclosure How-To

You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

1. Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email. Note: Please include JLLeitschuh Disclosure in the subject of your email so it is not missed.

Detecting this and Future Vulnerabilities

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.

I'm not an employee of GitHub, I'm simply an open-source security researcher.

Source

This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly handcrafted to bring this security fix to your repository.

The source code that generated this PR can be found here: Zip Slip

Why didn't you disclose privately (ie. coordinated disclosure)?

This PR was automatically generated, in-bulk, and sent to this project as well as many others, all at the same time.

This is technically what is called a "Full Disclosure" in vulnerability disclosure, and I agree it's less than ideal. If GitHub offered a way to create private pull requests to submit pull requests, I'd leverage it, but that infrastructure, sadly, doesn't exist yet.

The problem is that, as an open source software security researcher, I (exactly like open source maintainers), I only have so much time in a day. I'm able to find vulnerabilities impacting hundreds, or sometimes thousands of open source projects with tools like GitHub Code Search and CodeQL. The problem is that my knowledge of vulnerabilities doesn't scale very well.

Individualized vulnerability disclosure takes time and care. It's a long and tedious process, and I have a significant amount of experience with it (I have over 50 CVEs to my name). Even tracking down the reporting channel (email, Jira, etc..) can take time and isn't automatable. Unfortunately, when facing problems of this scale, individual reporting doesn't work well either.

Additionally, if I just spam out emails or issues, I'll just overwhelm already over-taxed maintainers, I don't want to do this either.

By creating a pull request, I am aiming to provide maintainers something highly actionable to actually fix the identified vulnerability; a pull request.

There's a larger discussion on this topic that can be found here: https://github.com/JLLeitschuh/security-research/discussions/12

Opting Out

If you'd like to opt out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/security-research
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Sponsorship & Support

This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.

This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/16

Bumps hibernate-validator from 5.0.1.Final to 6.0.23.Final.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps jetty-server from 8.1.8.v20121106 to 10.0.10.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.