Angular should handle errors from backend better

[mraible]

Overview of the issue

Today, I noticed that if you return a 401 from a backend method, the Angular UI will redirect you to / and log you out. To work around this, I tried returning a 403 instead. This is better because it doesn't log you out but shows a blank screen.

Code that throws the exception:

throw new ResponseStatusException(HttpStatus.FORBIDDEN, "error.http.403");

Motivation for or Use Case

The error is in the console, and it should be in the UI too.

Reproduce the error

Create an app with Angular, add the exception to a method, and hit that method with a call from the UI.

blog@0.0.1-SNAPSHOT /Users/mraible/Downloads/blog
└── generator-jhipster@8.0.0

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

.yo-rc.json file

{
  "generator-jhipster": {
    "applicationType": "monolith",
    "authenticationType": "jwt",
    "baseName": "blog",
    "buildTool": "maven",
    "cacheProvider": "ehcache",
    "clientFramework": "angular",
    "clientTestFrameworks": [
      "cypress"
    ],
    "clientTheme": "none",
    "creationTimestamp": 1701088333195,
    "cypressAudit": true,
    "cypressCoverage": true,
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "devServerPort": 4200,
    "enableGradleEnterprise": null,
    "enableHibernateCache": true,
    "enableSwaggerCodegen": false,
    "enableTranslation": true,
    "entities": [
      "Blog",
      "Post",
      "Tag"
    ],
    "gradleEnterpriseHost": null,
    "jhipsterVersion": "8.0.0",
    "languages": [
      "en",
      "es"
    ],
    "lastLiquibaseTimestamp": 1701088513000,
    "messageBroker": false,
    "microfrontend": null,
    "microfrontends": [],
    "nativeLanguage": "en",
    "packageName": "org.jhipster.blog",
    "prodDatabaseType": "postgresql",
    "reactive": false,
    "searchEngine": false,
    "serverPort": null,
    "serverSideOptions": [],
    "serviceDiscoveryType": false,
    "testFrameworks": [
      "cypress"
    ],
    "websocket": false,
    "withAdminUi": true
  }
}

Environment and Tools

openjdk version "21" 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)

git version 2.39.3 (Apple Git-145)

node: v18.18.2
npm: 9.8.1

Docker version 24.0.6, build ed223bc

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

JDL entity definitions

@ChangelogDate("20231127123313")
entity Blog {
  name String required minlength(3)
  handle String required minlength(2)
}
@ChangelogDate("20231127123413")
entity Post {
  title String required
  content TextBlob required
  date Instant required
}
@ChangelogDate("20231127123513")
entity Tag {
  name String required minlength(2)
}
relationship ManyToOne {
  Blog{user(login)} to User with builtInEntity
  Post{blog(name)} to Blog
}
relationship ManyToMany {
  Post{tag(name)} to Tag{post}
}

search Blog, Post, Tag with no
paginate Post, Tag with infinite-scroll

[atomfrede]

Is this a regression? I am pretty sure at least 403 have once been handled in another way

[mraible]

I tested my jhipster7-demo project and the bug happens there too. When you enter a URL for an entity that you don't have access to, you're logged out and redirected to the login page.

[mraible]

The 401 is caught by Angular in auth-expired.interceptor.ts. If I change it to a 403, the behavior is the same in JHipster 7.

[atomfrede]

Interesting. Totally agree we should fix/change that

[mraible]

I added a bug bounty.

[atomfrede]

Looking at the vue code, I think vue is handling these kind of errors, maybe I was thinking about that (didn't check react)

[atomfrede]

@mraible At least for 403 I can't reproduce this. The frontend shows a fine message

[mraible]

@atomfrede Does this happen when you click on an item that you don't have access to? In my case, I'm changing the ID in the URL. You can clone my example, add a couple of posts that belong to different blogs, then try to access one that you shouldn't be able to.

[atomfrede]

Yes I just clicked on the link. Will try it by changing the id in the url.

[atomfrede]

@mraible You're right. Entering the url directly in the adressbar leads to an empty page

EDIT: I have found the issue, will do a PR later today. TL;DR; the issue is, in case you try to access the page directly a navigation error occurs, which is not handled, while when clicking the link the http request is handled during route transition (which does not occur when accessing the route directly, as far as I remember angular routing)