Generate jHipster server app without security or authentication

[Alan-CS]

Overview of the issue

I generated a server app (using jHipster version 4.9.0) using the following command by selecting the default JWT security:

jhipster --skip-client --with-entities --skip-user-management

Upon running above app, you can call GET api's directly (from a rest client such as postman or even directly from the browser), without providing any Authorization header (aka the JWT token). Essentially, security is disabled. But in reality, calling the GET api without providing the JWT token in the Authorization header should return a HTTP 401 (Not authenticated).

Motivation for or Use Case

Security should not be disabled for a stand alone server app. However, by generating the app as shown above, security is disabled.

Reproduce the error

1. Generate the app using: jhipster --skip-client --with-entities --skip-user-management
2. Call the GET api for one of your entities using Postman (or directly from browser)
3. You can accomplish step 2 without providing any Authorization header (with the JWT token)
4. Step 3 should not be allowed since you should get back a response of HTTP 401 (Not authenticated)

Related issues

Please refer to this old issue.
Also, the stack overflow question for this issue is here.

Suggest a Fix

1. Instead of fixing this issue, it would be nice to be able to skip security on a standalone server app as also requested here.
2. Skipping security is helpful to quickly create a mock server that will serve JSON without involving any security/authentication.
3. This will be very helpful to a developer testing their api without worrying about authentication or worrying about Authorization headers etc.
4. With security bypassed, you could quickly go from an E-R diagram to a mock server that provides the JSON and implements the Rest API.
5. Such a mock server would have wide appeal as a test/mock server.

JHipster Version(s)

4.9.0

JHipster configuration

Welcome to the JHipster Information Sub-Generator
Using JHipster version installed locally in current project's node_modules
Executing jhipster:info
Options:

JHipster Version(s)

/A-Project/App-Server
└── [email protected] 

JHipster configuration, a .yo-rc.json file generated in the root folder

.yo-rc.json file

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "com.app.myapp"
    },
    "jhipsterVersion": "4.9.0",
    "baseName": "MYAPP",
    "packageName": "com.app.myapp",
    "packageFolder": "com/app/myapp",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "hibernateCache": "ehcache",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "mysql",
    "prodDatabaseType": "mysql",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "gradle",
    "enableSocialSignIn": false,
    "enableSwaggerCodegen": false,
    "jwtSecretKey": "replaced-by-jhipster-info",
    "enableTranslation": false,
    "applicationType": "monolith",
    "testFrameworks": [
      "gatling"
    ],
    "jhiPrefix": "jhi",
    "skipClient": true,
    "skipUserManagement": true,
    "clientPackageManager": "yarn"
  }
}

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory

JDL entity definitions

entity AppUser (app_user) {
  firstName String,
  lastName String,
  email String,
  tier String
}

Environment and Tools

java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

git version 2.13.6 (Apple Git-96)

node: v6.10.2

npm: 5.5.1

yeoman: 1.8.5

yarn: 1.2.1

Docker version 17.03.1-ce, build c6d412e

docker-compose version 1.11.2, build dfed245

Execution complete

Entity configuration(s) entityName.json files generated in the .jhipster directory

The error is not related to Entity generation.

Browsers and Operating System

MACOS Sierra with latest version of Chrome Version 61.0.3163.100 (Official Build) (64-bit).

• Checking this box is mandatory (this is just to show you read everything)

[PierreBesson]

A few remarks :
First, how do you intend to generate the jwt if you have no user management code ?
If we still had security with --skip-user-management, it would not work out of the box and this is the most important for us.

1. Allowing skipping security

For me it is trivial to remove the security code. Also adding this new option would require work from us just to accommodate the people who don't want to use our security solution (which is the standard one provided by spring security).

2. Skipping security is helpful to quickly create a mock server that will serve JSON without involving any security/authentication.

A better way to do that IMO is to mock the API from the swagger definition.

3. This will be very helpful to a developer testing their api without worrying about authentication or worrying about Authorization headers etc

If you want to disable security for integrations testing, you can use @Profile annotations to load a different SecurityConfiguration depending on the profile. You might even be able to do this just with properties...

So I'm against this proposed feature. However feel free to continue the discussion.

[gmarziou]

If you don't want to worry with security, you could do what I proposed here.

[pascalgrimaud]

What I understand here : I think @Alan-CS wants to generate, with jhipster --skip-client --with-entities --skip-user-management :

• a monolith
• without the angular part
• without user table
• but the API should be secured

In this case, as written by @gmarziou on StackOverFlow, we should generate the SecurityConfiguration file, but we didn't. The code to change is here:
https://github.com/jhipster/generator-jhipster/blob/master/generators/server/files.js#L257

Then, there are some works to do in SecurityConfiguration to manage the skip-user-management

[PierreBesson]

@pascalgrimaud I'm questioning if we really need the Security code for --skip-user-management. After all there is no mechanism to generate a valid token in this case, is there ?

[pascalgrimaud]

After reading the ticket again, jhipster --skip-client --with-entities --skip-user-management is simply a microservice project, with no service discovery (this part is your code @PierreBesson right?). And for that, we generate MicroserviceSecurityConfiguration

Then, if you want to disable the security, simply add permitAll in the MicroserviceSecurityConfiguration
Otherwise, you have to manage a valid token to access to the API

Am I correct, or should I go to sleep ?

[Alan-CS]

I am not familiar with the jhipster codebase. But what I was trying to say is this:

Allow the user to specify a new flag (say --generate-mock-server) with the following functionality:

1. If the user has also specified --skip-client and --skip-user-management, then this flag will simply skip security (Don't ask for security option and don't generate other security artifacts SecurityConfiguration.java)

2. Ignore this new flag (or throw some error) if the other two flags are not specified.

@PierreBesson I see your point about using swagger defs or to use @Profile etc. But this requires knowledge of swagger or knowing how to load security configs etc. Some QA people might not have this knowledge.

@gmarziou I read your proposal here. However, again, this requires modifying files/tokens etc. Again, some QA people might not have this knowledge.

However, the way I have proposed, anyone who does not know the details around tokens/profiles/configurations/swagger etc. can easily generate a mock server that can be used very easily (without passing any headers/tokens etc.) from rest clients. Such a mock server could be helpful in corporate test departments.

Infact, for my own development, I wanted such a server, and I was pleasantly surprised when by using the above options, I could generate the server that essentially bypasses security/auth.

I would love to have this functionality, which has also been requested by others in the past.

[ramzimaalej]

@Alan-CS can you explain the testing strategy you are trying to implement? Why QA needs to overcome security and which kind of testing are they doing?

[Alan-CS]

To test an api (what are the requests/responses), sometimes security is not always desired as it comes in the way. e.g., you have to provide additional headers etc. which really are not part of your response/testing. So, in such circumstances, to do some quick testing, it would be nice to have security disabled.

[ramzimaalej]

I would argue, why do you need to test an API manually. This is something we can easily achieve by writing automated tests

[Alan-CS]

@ramzimaalej , in addition to ad-hoc testing(without necessarily writing automated tests etc.), sometimes you also need to quickly prototype a front end without much worrying about the backend (and other orthogonal issues such as security etc.).

For example, I am working on a project where I am building a jHipster client only app and someone else is developing the server. Before I integrate with their server, I wanted to quickly create a mock server so that I could test my front end against the mock server, which I will later swap with the actual server.

The node module json-server provides such functionality.
I thought it would be cool for jHipster to provide a Java based solution which would naturally make it easy to mock a REST server right from jHipster JDL after doing some E-R modeling.

[pascalgrimaud]

So if I understand well, it's a feature request and a bug report too. Sorry, I'm a bit confuse here.

You want to generate a JHipster server app without security or authentication.
You can already do it with these options:

• microservice
• no service discovery
• then, inside the MicroserviceSecurityConfiguration class, add a permitAll to your API -> for this part, we won't add a new flag 'skip security' to manage it, as it's against our policy 2 http://www.jhipster.tech/policies/

About the bug, when using skip user management and skip cliengt, we should simply create a SecurityConfiguration, which should be exactly the same than MicroserviceSecurityConfiguration.

[jdubois]

Indeed it's not really hard to add/remove the security part.
We don't advertise the "mock server" part, but indeed that's very easy to do with JHipster, using security (or removing it) - have a look at our Swagger UI, that will also help you.
Please note that those are flags, and so are for "advanced users", and that we use them to generate the microservices - so we can't modify their behavior easily, or we will break the way microservices work.

[Alan-CS]

@pascalgrimaud Yes, it is both a feature request and bug report.

So, for feature request, you can ignore what I said. I will try the microservice with no discovery as you suggested or as @jdubois suggested.

However, for the bug fix, you can probably fix it by creating SecurityConfiguration.java.

Thanks to all for their help/advice.

[ramzimaalej]

@Alan-CS if you need a mock server, take a look at https://github.com/swagger-api/swagger-codegen

If the backend developer has already the swagger doc of the API, you can easily stub the server us swagger-codegen