@arsedizioni/ars-utils 22.5.15 → 22.5.16

package/fesm2022/arsedizioni-ars-utils-clipper.common.mjs

@@ -2185,6 +2185,19 @@ function isAuthEndpoint(url) {
 function isSessionExpired(errorStatus, url) {
     return errorStatus === 401 && !isAuthEndpoint(url);
 }
+/**
+ * Returns whether the URL is the silent link probe, whose failures must never reach the user.
+ *
+ * `/session/status` runs unconditionally at every bootstrap, including for users who never linked
+ * Clipper at all. When the API is unreachable, reporting that failure would show "Clipper non
+ * disponibile" to somebody who never asked Clipper for anything: the probe simply stays unanswered
+ * and the link state keeps whatever the stored hint says.
+ * @param url - The request URL.
+ * @returns True when the URL is the status probe.
+ */
+function isStatusProbe(url) {
+    return url.includes('/session/status');
+}
 /**
  * Resolves a user-facing error message based on the HTTP status code.
  *
@@ -2331,7 +2344,11 @@ function clipperAuthInterceptor(serviceUri, flags = ClipperServiceFlags.None) {
             // at all. Everything that gets here is a Clipper request anyway: the others returned
             // before the pipe was built.
             const errorStatus = parseInt(error?.status ?? '0');
-            if (isServiceUnavailable(error)) {
+            if (isStatusProbe(authenticatedRequest.url)) {
+                // The silent probe stays silent: its caller reads the outcome from the stream, nobody
+                // else needs to hear about it.
+            }
+            else if (isServiceUnavailable(error)) {
                 // Three attempts over ten seconds and the API is still not answering. There is nothing
                 // left to retry, so the host application is told once, however many requests were in
                 // flight.
@@ -2392,12 +2409,17 @@ class ClipperLoginService {
     // BOOTSTRAP
     ////
     /**
-     * Validates a context that survived a page refresh before trusting it.
+     * Establishes the session state at bootstrap by asking the API — the only party that can read the
+     * HttpOnly cookie — whether this browser still holds one.
      *
      * Called by `ClipperService.initialize`, right after `ClipperCoreService.initialize`, so a
-     * consumer gets the restore for free and never has to know this method exists. The auth cookie is
-     * HttpOnly and may have expired while the stored context lived on, so a stored context only ever
-     * means "there WAS a session" — this is what turns it into "there is one".
+     * consumer gets the restore for free and never has to know this method exists.
+     *
+     * The probe now runs UNCONDITIONALLY, where it used to run only when a stored context existed.
+     * The stored context is just a hint — "this browser signed in at some point" — and the cookie can
+     * outlive it: local storage cleared while the month-long cookie stayed put made this library
+     * declare "no link" with a perfectly valid session in the browser. The API is the only source of
+     * truth on the matter, so it is asked every time.
      *
      * A host application that drives its own return from an external provider, or that starts on its
      * own sign-in page, should call `core.setLoggedIn(false)` before bootstrapping rather than let
@@ -2408,30 +2430,53 @@ class ClipperLoginService {
         if (this.initialized)
             return;
         this.initialized = true;
-        if (this.core.loggedIn()) {
-            this.core.loggingIn.set(true);
-            this.restoreSession();
-        }
+        this.core.loggingIn.set(true);
+        this.restoreSession();
     }
     /**
-     * Asks `/session/me` whether the restored session is still alive. On success the login is
-     * finalised from the current claims; on a dead session the interceptor's 401 handling takes over.
+     * Asks `/session/status` whether this browser holds a live session, and hydrates the context
+     * through {@link me} when it does.
      *
-     * Nothing is cleared on failure, and that is deliberate: a failure here is not proof of a dead
-     * session — the API may be unreachable, the proxy may have answered 502, the device may be
-     * offline. Clearing on any of those would sign the user out with a perfectly valid cookie.
+     * The probe is silent by construction: `/session/status` never answers 401, so a visitor who
+     * never signed in — or a cookie whose session has died — comes back as `connected: false` with no
+     * error broadcast and no dialog. Only then is the stale stored context cleared, so the `loggedIn`
+     * signal tells the truth at every bootstrap.
+     *
+     * Nothing is cleared on a transport failure, and that is deliberate: an unreachable API is not
+     * proof of a dead session — the proxy may have answered 502, the device may be offline — and
+     * clearing on any of those would sign the user out with a perfectly valid cookie.
      * @returns void
      */
     restoreSession() {
-        this.me()
-            .pipe(finalize(() => this.core.loggingIn.set(false)))
+        // Whether the probe handed over to `/session/me`, which then owns lowering `loggingIn`.
+        let restoring = false;
+        this.status()
+            .pipe(finalize(() => { if (!restoring) {
+            this.core.loggingIn.set(false);
+        } }))
             .subscribe({
             next: r => {
-                if (r?.success) {
-                    this.broadcastService.sendMessage(ClipperMessages.LOGIN_COMPLETED);
+                if (r?.success && r.value?.connected) {
+                    restoring = true;
+                    this.me()
+                        .pipe(finalize(() => this.core.loggingIn.set(false)))
+                        .subscribe({
+                        next: m => {
+                            if (m?.success) {
+                                this.broadcastService.sendMessage(ClipperMessages.LOGIN_COMPLETED);
+                            }
+                        },
+                        // Consumed so the rethrown error is not reported a second time as an unhandled one.
+                        error: () => { }
+                    });
+                }
+                else if (this.core.loggedIn()) {
+                    // The stored context outlived its session: drop it, or the next bootstrap would keep
+                    // claiming a session that is gone.
+                    this.core.clear(true);
                 }
             },
-            // Consumed so the rethrown error is not reported a second time as an unhandled one.
+            // Transport failure: keep the stored hint, the next bootstrap will ask again.
             error: () => { }
         });
     }
@@ -2496,6 +2541,18 @@ class ClipperLoginService {
             .post(this.core.serviceUri + '/session/logout', {})
             .pipe(finalize(() => this.core.clear(true)), catchError(() => of({ success: false })));
     }
+    /**
+     * Asks the API whether this browser holds a live session, without ever failing with a 401: the
+     * route is anonymous and answers `connected: false` to a caller with no session. This is the one
+     * honest way to know the link state — the auth cookie is HttpOnly and belongs to the API's host,
+     * so it cannot be read from here, and its presence would prove nothing anyway, since the session
+     * also lives server-side and may have been revoked or evicted.
+     * @returns An observable emitting the API result wrapping the session status.
+     */
+    status() {
+        return this.httpClient
+            .get(this.core.serviceUri + '/session/status');
+    }
     /**
      * Reads the current session from the server, which resolves it from the auth cookie claims
      * without touching the database. Used to restore the state after a page refresh instead of
@@ -3313,10 +3370,12 @@ class ClipperService {
      */
     initialize(serviceUri, appUri, flags = ClipperServiceFlags.None) {
         this.core.initialize(serviceUri, appUri, flags);
-        // Second, and in this order: the core sets the base URI that `/session/me` is built from, and
-        // it no longer declares a session from what local storage holds. Validating that context is
-        // what `ClipperLoginService.initialize` does, and doing it from here means a consumer keeps
-        // calling one method to bootstrap, exactly as before.
+        // Second, and in this order: the core sets the base URI that `/session/status` and
+        // `/session/me` are built from, and it no longer declares a session from what local storage
+        // holds. Asking the API whether a session actually exists is what
+        // `ClipperLoginService.initialize` does — unconditionally, since the HttpOnly cookie can
+        // outlive any local hint — and doing it from here means a consumer keeps calling one method to
+        // bootstrap, exactly as before.
         this.session.initialize();
     }
     /**