jhipster / generator-jhipster

JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures.
https://www.jhipster.tech
Apache License 2.0
21.54k stars 4.02k forks source link

Route reset/request is not working #7773

Closed Pinny3 closed 6 years ago

Pinny3 commented 6 years ago
Overview of the issue

Running the production environment the page ../reset/request is only accessible if a user is already logged in. If the user is not logged in the home page is showing immediately if this url is called. Running a dev environment everything is working as expected.

Motivation for or Use Case

A User should initialize the password reset if he's not logged in (otherweise it makes no sense).

Reproduce the error

Do a build with

./mvnw -Pprod package

and let it run.

Related issues
Suggest a Fix

I have no idea how to fix it since I don't see any errors anywhere.

JHipster Version(s)

v4.14.4

JHipster configuration
.yo-rc.json file
{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "de.datau",
      "nativeLanguage": "en"
    },
    "jhipsterVersion": "4.14.4",
    "baseName": "frontend",
    "packageName": "de.datau",
    "packageFolder": "de/datau",
    "serverPort": "8080",
    "authenticationType": "uaa",
    "uaaBaseName": "uaa",
    "cacheProvider": "hazelcast",
    "enableHibernateCache": false,
    "websocket": false,
    "databaseType": "no",
    "devDatabaseType": "no",
    "prodDatabaseType": "no",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": "consul",
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "enableSwaggerCodegen": false,
    "clientFramework": "angularX",
    "useSass": false,
    "clientPackageManager": "yarn",
    "applicationType": "gateway",
    "testFrameworks": [],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": [
      "en",
      "de"
    ]
  }
}
JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory
JDL entity definitions
/**
 * DataU simple model
 */
entity Tenant (tenant) {
  name String required
}
entity Datasource (datasource) {
  salutation String required,
  academicTitle String,
  firstName String required,
  lastName String required,
  organisationName String,
  gender Gender required,
  email String required pattern(/^[^@\s]+@[^@\s]+\.[^@\s]+$/),
  phone String required
}
entity Address (address) {
  addressLine1 String required,
  addressLine2 String,
  zip String required,
  city String required,
  country String required
}
entity BancAccount (banc_account) {
  bIC String required,
  iBAN String
}
entity AditionalValue (aditional_value) {
  name String required,
  value String required
}
entity Consent (consent) {
  placedDate Instant required,
  status ConsentStatus required
}

enum Gender {
  MALE,
  FEMALE,
  ORGANISATION
}

enum ConsentStatus {
  ERTEILT,
  AUSTEHEND,
  ENTZOGEN
}

relationship OneToMany {
  Tenant{tenant} to Datasource{tenant(name) required},
  Datasource{adresses} to Address{datasource(email)},
  Datasource{bancAccounts} to BancAccount{datasource(email)},
  Datasource{addOnPair} to AditionalValue{datasource(email)},
  Datasource{consentChange} to Consent{datasource(email) required}
}

service Tenant, Datasource, Address, BancAccount, AditionalValue, Consent with serviceClass
microservice Tenant, Datasource, Address, BancAccount, AditionalValue, Consent with backend
paginate Datasource, Consent with pagination

Environment and Tools

java version "10" 2018-03-20 Java(TM) SE Runtime Environment 18.3 (build 10+46) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)

git version 2.17.1

node: v6.14.2

npm: 5.8.0

gulp: [22:22:51] CLI version 2.0.1

yeoman: 2.0.2

yarn: 1.6.0

Docker version 18.03.1-ce, build 9ee9f40

docker-compose version 1.21.1, build 5a3f1a3

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

This seems to be not an entity problem.

Browsers and Operating System

Ubuntu Linux Browser: Chrome

ruddell commented 6 years ago

I can't reproduce this. The UI path is unsecured by default, are you sure you are navigating to the correct URL? http://localhost:8080/#/reset/request

Pinny3 commented 6 years ago

First of all, thanks for your fast reply.

I do call the right route. You can give it a try here

http://frontend.datau.christian-hartmann.de/#/reset/request

(or using the link 'forgot password' in the sign-in box).

As mentioned it is working properly if I let it run locally, but after building it with

./mvnw -Pprod package

it is not working anymore. Anything seems to be misconfigured using the prod-profile.

Maybe it is worth to mention that the setup is a a micorservice setup according to the documentation using the frontend as the gateway together with a uaa server.

ruddell commented 6 years ago

I'm running in Prod via Docker so it should be the same as on a remote server (unless you have some proxy between that might be affecting it).

Looking at your minified code, this section in user-route-access-service.ts looks weird. You're returning console.log? I would try without those modifications

return l.prototype.canActivate = function(l, n) {
            var u = l.data.authorities
              , t = this.checkLogin(u, n.url);
            return console.log("CanActivateResult ", t),
            console.log("CanActivateResult2 ", Promise.resolve(t).then(function(l) {
                console.log("CanActivateResult3 ", l)
            })),
            t
        }

From my working reproduction, it should look like:

 return l.prototype.canActivate = function(l, n) {
                var u = l.data.authorities;
                return this.checkLogin(u, n.url)
            }
Pinny3 commented 6 years ago

Once again, thank you for your fast reply.

I have setup this logging statements for debugging purpose. I've just reverted the class UserRouteAccessService to the initial state generated by the Jhipster-Generator and done a new deployment.

However it is still not working. May you please recheck at

http://frontend.datau.christian-hartmann.de/#/reset/request

?

Thank you in advance....

deepu105 commented 6 years ago

This could be result of some modifications you have done as well. Can you generate a new app using the same config and try it? If that works then you can compare code of the new and your current app to see what might be causing issue.

On Thu, 14 Jun 2018, 7:38 am Christian Hartmann, notifications@github.com wrote:

Once again, thank you for your fast reply.

I have setup this logging statements for debugging purpose. I've just reverted the class UserRouteAccessService to the initial state generated by the Jhipster-Generator and done a new deployment.

However it is still not working. May you please recheck at

http://frontend.datau.christian-hartmann.de/#/reset/request

?

Thank you in advance....

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/7773#issuecomment-397176861, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDlFy1g7sMbyCG0Ctjww7c1uiQbK1xOks5t8fbFgaJpZM4Um4M7 .

Pinny3 commented 6 years ago

I've just set it up from scratch, changed nothing and do a new deployment.

However the error still exists...... I don't see any reason why.

One more thing is to mention that the frontend is running behind a Elastic-Load-Balancer at AWS.

Do you have got any clue what's wrong here?

ruddell commented 6 years ago

@Pinny3 See the linked PR for the fix. The issue happens because we request the account when accessing the /#/reset/request route, causing a 401 which redirects to home for UAA apps.

I couldn't reproduce earlier because I was getting 500 errors for /uaa/api/account instead of 401 errors. Once the apps and consul fully loaded I could reproduce