How to enable Basic Authentication in Nginx for an Angular path?

Question

I have an angular application where I want to protect a specific path with basic HTTP authentication. The application paths are meusite.com.be/#/example-path.

The Nginx configuration file looks like this:

location /#/path-to-protect {
    auth_basic           "Area Restrita";
    auth_basic_user_file conf/.htpasswd;
}

But the path does not ask for authentication when accessed.

I tested with other paths without # and it worked normally.

Answer 1

You do not have to do this way. The part of the Urls after the character # is never passed to the server. - This is in the specification of the Urls themselves.

Angular uses this feature precisely to perform client-side operations - it executes code depending on what comes after "#" - but that part of the URL is never passed to the server - and therefore no possible configuration on the server will be able to do anything with a URL that only is distinguished from other by things that come after the "#".

If you want to lock screens for users of a "single page" web-app, you have to do this with Javascript code at the very angle - you can ask for an HTTP ID when the person accesses the site for the first time, and, on the server side, provide a paper variable (scroll) of the current user that the client-side application will take into account for all operations (that way you don’t have to manage authentication and client-side passwords if you don’t want to) - but even doing so, you will need to lock the data Urls - "API"s used by your application, depending on that role. Why you always have to keep in mind that it is the user of the page who in full control of the client-side application execution environment - just log into the Javascript console and directly change any variable used by Angular. (Then he could change the role from "anonymous" to "administrator" and unlock everything).

In short:

1. You can’t lock screens and "pages" of the amphar by configuring the URL on the server side;
2. You even have to lock, for aesthetic purposes, access to some screens and features just by fiddling with the client code. But any user who actually has something to gain from this can have access to these screens by changing the variables in Angular directly
3. If you separate the really important data resources into separate Urls, even if they’re only used internally by Angular, you can control access to them via a basic HTTP authentication - but I don’t think you can require this authentication, which causes the browser to display a pop-up, and etc... in an "ajax" request made by Angular: you will have to ask for authentication once the user accesses the application the first time, and instruct unauthorized users to use something like "guest" password "guest" - and then configure NGINX accordingly: (access only part of the resources for the "guest" user, and everything for users with a valid login and password).
4. Finally, the right and elegant way to do this is to actually program the Backend side, using some conceptualized framework and programming language, and do the whole authentication and authorization part there. With the use of framework template systems, you can even split the Angular application, and only allow the client to climb the screens he has access to, according to his role in the system.

(annex) information on URL schemes

Here the specification of Uris and Urls by Internet Engineering Task Force: https://tools.ietf.org/html/rfc3986

And in section 3.5, "Fragments", you will find:

Fragment Identifiers have a special role in information Retrieval
as systems the Primary form of client-side Indirect referencing,
allowing an Author to specifically identify aspects of an existing
Resource that are only Indirectly provided by the Resource Owner. As such, the Fragment Identifier is not used in the Scheme-specific
Processing of a URI; Instead, the Fragment Identifier is separated
from the Rest of the URI prior to a dereference, and Thus the
Identifying information Within the Fragment itself is dereferenced
solely by the user agent, regardless of the URI Scheme.

Translating with some notes:

Fragment identifiers have a special role in retrieval of information as the primary form of references client-side indirect, allowing an author to identify specifically aspects of an existing Source that are provided only indirectly by the owner of the Resource. Thus, the fragment identifier is not used in URI processing specified for the scheme; instead, the fragment identifier is separate the rest of the URI before a de-reference (search in the server, in the case of HTTP), and therefore the identifier information within the fragment itself is de-referenced only in the user-agent (browser, in the case of web pages) whatever the scheme of URI.