GitHub 页面不允许使用 Angular 自动重定向，它显示 404 GitHub 页面

Question

GitHub Pages shows me 404 when I use automatic redirection to the login path or try to directly access that path other than the base path in Angular.

I created an application in Angular that automatically redirects to "/auth/login" when it detects that the session has not been logged in.

So the problem I have is if I directly access the URL "user.github.io/example-app" the application works fine and perfect, but if I directly access the URL "user.github.io/example-app/auth/login" (or any path other than the parent) throws me the 404 GitHub Pages.

Even I am using PWA and when installing the app on my Android device it directly throws the 404 of GitHub Pages.

Note:

I have also noticed that if I use Lighthouse and do a test using http-server, it also throws a 404 when executing the test.

Using http-server I can install the application on Windows and this does show me the application, not the 404 that happened to me with GitHub Pages.

Answer 1

tl;dr Use HashLocationStrategy or Scully .

---

Angular, by default, uses the History API for routing.

This system allows the JavaScript to tell the browser:

I have manipulated the DOM so the user is effectively looking at a new page. If you went to this URL then the server would send you this page .

Unfortunately, Angular does nothing to make that possibly by default. There are three approaches that are used to get the server to play ball.

• Configure the server to serve the bootstrap HTML document and then depend on JavaScript to update it for the URL (this is bad for caching, bad for HTTP status codes, back for search engines, and not possible on Github Pages).
• Implement server-side rendering (eg with Angular Universal ) where you use Node.js or similar to generate HTML server side for initial page loads using the same code as you would send to run in the browser. (This is not possible on Github Pages).
• Static site generation (eg with Scully ) where you generate static HTML documents for all your pages at build time.

Alternatively, keep having a single HTML document, ditch the history API, and replace it with a URL scheme that is based on the premise that you have only a single HTML document. Use the HashLocationStrategy ).