Generator-jhipster: Accessing the registration page with UAA [v4.9.0]

[mat3e]

Overview of the issue

When using JHipster 4.9.0 and UAA, there is an issue with accessing the registration page. There is 401 Unauthorized error in the browser's console (as the result of the GET request to http://localhost:8080/uaa/api/account).

Motivation for or Use Case

Registrations should be possible in the out of the box, generated version.

Reproduce the error

You have to generate an app with UAA through JHipster 4.9.0.

Related issues

I'm not aware of this.

Suggest a Fix

There were a changes in UAA recently. From the first overview I found generator-jhipster/generators/client/templates/angular/src/main/webapp/app/shared/auth/_user-route-access-service.ts as the reason of the problem.

Previously when the route had no authorities, checkLogin was not executed. Problem has to be related with principal.identity(), executed inside checkLogin.

The quickfix for me was to copy

if (!authorities || authorities.length === 0) {
    return true;
}

back to its original place, but it was moved from there for a purpose

// We need to call the checkLogin / and so the principal.identity() function, to ensure,
// that the client has a principal too, if they already logged in by the server.
// This could happen on a page refresh.

I'd say, the target solution requires a better understanding of `principal.identity()` and rethinking it with the recently registered user in mind. ##### **JHipster Version(s)** 4.9.0 ##### **JHipster configuration** ##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**

.yo-rc.json file

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "io.github.mat3e.jhipster.taskr",
      "nativeLanguage": "pl"
    },
    "jhipsterVersion": "4.9.0",
    "baseName": "uaa",
    "packageName": "io.github.mat3e.jhipster.taskr",
    "packageFolder": "io/github/mat3e/jhipster/taskr",
    "serverPort": "9999",
    "authenticationType": "uaa",
    "hibernateCache": "no",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "mongodb",
    "devDatabaseType": "mongodb",
    "prodDatabaseType": "mongodb",
    "searchEngine": false,
    "messageBroker": "kafka",
    "serviceDiscoveryType": "consul",
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "enableSwaggerCodegen": false,
    "enableTranslation": true,
    "applicationType": "uaa",
    "testFrameworks": [
      "cucumber"
    ],
    "jhiPrefix": "jhi",
    "skipClient": true,
    "nativeLanguage": "pl",
    "languages": [
      "pl",
      "en"
    ],
    "clientPackageManager": "yarn"
  }
}

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

No entities in UAA.

Environment and Tools

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

git version 2.9.0.windows.1

node: v8.2.1

npm: 5.3.0

bower: 1.7.9

yeoman: 2.0.0

yarn: 0.27.5

Docker version 17.06.2-ce, build cec0b72

docker-compose version 1.14.0, build c7bdf9e3

Browsers and Operating System

I'm working on Windows.

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

[gzsombor]

I haven't been able to try it, but my guess is the following happens:

• UserRouteAccessService calls Principal.identity()
• Principal.identity() calls Account.get()
• Account.get calls the uaa/api/account http endpoint
• The response is intercepted by AuthExpiredInterceptor - here it differs the UAA and session based implementation, in the UAA code path, there is no separate treatment of the 401 response for the uaa/api/account call - here.

I guess, similar exception is needed there.

[xetys]

I will check this

[xetys]

Ok, I tried that and see 2 options

1. remove canActivate: [UserRouteAccessService] from register.route.ts, as this route actually should not be permitted for authenticated users (as I am interpreting the use-case for that service)
2. move the authorities block back to it's previous position, but I'm not sure, why @mraible moved it away...

I would rather say 1, as I see no reason for the user route access been set on that route

[mraible]

@xetys All my changes were designed for oauth2. If I messed something up for uaa, that was unintentional.

[ruddell]

That change was merged in to @mraible's branch from master, the original Pull Request can be found https://github.com/jhipster/generator-jhipster/pull/6420

Option 1 looks simple and makes sense

[xetys]

that's ok, I just don't get why you moved that lines? If there is a good reason, then let's discuss if we need the user-route-access restriction on register route. Maybe some of the frontend gurus? @deepu105

[gzsombor]

I've moved the lines, because of #6190 and #6413 .
The register route should have an opposite rule - if the user logged in, they shouldn't be allowed to see the page

[xetys]

So...option 3: "AntiUserRouteAccessService" 😆

[xetys]

as it was already merged, is there any interest in an opposite service to UserRouteAccessService?

[mat3e]

It's not a must, but I think I'd add such a thing, maybe LoggedOutUserRouteAccessService.

And big thanks for the fix.