$RestxSession special header, more samples in AppModule generated file (app.name, security) & test harness for restx-core-shell

[fcamblor]

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

[fcamblor]

Provided some BasicPrincipalAuthenticator in AppModule.

This was not easy, specifically on the RestxSignature generation, because signature key is randomly generated.
I had to provide a mustache template block (function) to handle this.

[xhanin]

Good job!

I didn't think about the problem about the content to sign, using a template block is a neat approach. The downside is that you have to give the content twice (once to set it, once to sign it). Maybe we could do sg different: provide a toSessionCookies function used like this:

{{#toSessionCookies}}{"_expires":"2013-09-27T01:18:00.822+02:00","principal":"user1","sessionKey":"e2b4430f-9541-4602-9a3a-413d17c56a6b"}{{/toSessionCookies}}

The Function would be something like:

final String signatureKey = ...;
final String appName = ...;
[...]
     .put("toSessionCookies", new Function<String,String>(){
                @Override
                public String apply(String input) {
                    String signedInput = Crypto.sign(input, signatureKey.getBytes(Charsets.UTF_8));
                    return String.format("RestxSession-%s=%s; RestxSessionSignature-%s=%s", appName, input, appName, signedInput);
                    }
                })

WDYT?

[fcamblor]

Yup you're right, I was too happy to have something working yesterday (or may I say, this morning :-))

This signature key is a boring stuff to handle, not only in generator, but generally in spec tests.
Do you think it would be hard to go further and implement some sort of helper functions available directly in spec tests ?

I'm thinking about something like this :

wts:
  - when: |
      GET sessions/current
      withRestxSession({"_expires":"2013-09-15T18:30:41.234+02:00","principal":"admin","sessionKey":"e71a0f9f-9082-4626-bc34-3893c540566d"})
    then: |
      200
      { "key": "e71a0f9f-9082-4626-bc34-3893c540566d", "principal": { "principalRoles": [ "restx-admin" ], "name": "admin" } }

[xhanin]

Yup you're right, I was too happy to have something working yesterday (or may I say, this morning :-))

I understand, I didn't know about the template block, you did the hard work :)

Do you think it would be hard to go further and implement some sort of helper functions available directly in spec tests?

Very good idea! I'm wondering what the notation should be. The parentheses could imply some corner cases requiring to escape them in the content. Maybe it could be as simple as a specific header like entry, with a prefix to show it's special:

wts:
  - when: |
      GET sessions/current
      $RestxSession: {"_expires":"2013-09-15T18:30:41.234+02:00","principal":"admin","sessionKey":"e71a0f9f-9082-4626-bc34-3893c540566d"}
    then: |
      200
      { "key": "e71a0f9f-9082-4626-bc34-3893c540566d", "principal": { "principalRoles": [ "restx-admin" ], "name": "admin" } }

[fcamblor]

I like it : this is simple :-)

I go with it ! :)

[xhanin]

Great!

[fcamblor]

Just rebased branch over e69f9cc in order to fix merge issues on HelloResourceSpecTest mustache file

(note that I integrated, in 4006d87, some missing import in the mustache file, since PR #43 was already merged :-))

[fcamblor]

I added some integration tests for app new shell command.
It generates a project, then executes a mvn package on it and check if there isn't any error during build execution.

These tests take a few seconds (approx ~8s per app configuration on my laptop), so, I'm wondering if I shouldn't bind them on the integration-test maven phase instead of test phase.
OTOH, I don't think if we could really tests restx-core-shell with something else than integration tests.

Let me know if you want to move them in an it test category.

[xhanin]

Excellent! That makes it much more stable, yes! I don't mind too much about
having them in regular tests, so I'm fine with the current state.