GleamTech.DocumentUltimate 8.1.0

• .NETFramework 4.7.2

  • GleamTech.Common (>= 7.1.0)

• .NETStandard 2.0

  • GleamTech.Common (>= 7.1.0)
  • System.Drawing.Common (>= 6.0.0)
  • System.Security.Cryptography.Xml (>= 6.0.2)
  • System.Text.Encoding.CodePages (>= 6.0.1)

## Version 8.1.0 - April 24, 2026

 - **Fixed:** The fix back in `Version 7.5.8 - April 11, 2025` for parsing `Referer` http header was not sufficient.
   This warning was occasionally recorded in server's Event Log:
   `This operation is not supported for a relative URI.`

 - **Improved:** Ensured stability of cookieless session feature for iframe with a cross-domain URL.
   This feature (`GleamTechWebConfiguration.AutoCookielessSessionEnabled`) was first added in `Version 5.8.1 - November 23, 2020`.

 - **Added:** `GleamTechWebConfiguration.PathBaseForSessionEnabled` property that specifies whether
   to use request PathBase (correct cased application virtual path) for session cookie and not default path `/`.
   The default value is `true` so it's active by default.

   The problem with ASP.NET Core session is, if for example you have 2 app instances on the same domain:
   1. First visit to `/MyApp1`, the session cookie is created and set (with cookie path `/`).
   2. Then visit to `/MyApp2`, the session cookie exists (with cookie path `/`)
      but this app cannot decrypt it because their key ring is not shared.
      This causes unnecessary `Error unprotecting the session cookie` warnings in server's Event Log.
      A new session cookie is still created but the problem is the logging in `CookieProtection.Unprotect()` on exception.
 
   In ASP.NET classic, session cookie path also defaults to `/` and not to the application virtual path,
   though this does not cause a warning/error, but you get a new empty session with the existing session cookie.

   So, the best solution is to use correct cased application virtual path as session cookie path when available
   and not the default path `/`, to isolate session of all app instances on the same domain, for example:

   ```
   ApplicationVirtualPath:      /DocumentUltimate/AspNetWebFormsCS               ❌ (IIS canonical casing)
   Request.Path:                /documentultimate/aspNetWebFormsCS/Page.aspx     ✔ (actual request casing)
   PathBase (correct cased):    /documentultimate/aspNetWebFormsCS
   ```

   Cookie paths are case-sensitive so when not using the default path `/`,
   we ensure PathBase used for cookie path is correct cased (cased same as the one user typed in address bar).

   However, if you want to share the session cookie across all app instances on the same domain,
   set this to `false` (default ASP.NET Session behavior).

 - **Improved:** Normally, to have Session cookie work properly for an ASP.NET Core app hosted in IIS,
   "Load User Profile" property should be set to true for application pool used for that app.
   However for convenience, we will now use `Keys` subfolder under `GleamTechConfiguration.TemporaryFolder`
   by default in `AddGleamTech()` if `KeyManagementOptions.XmlRepository` is not explicitly set
   and if app is not hosted in Azure Apps.
   This is because if keys can not be persisted to a writable directory, they are stored in-memory
   and when the process shuts down (or application pool is recycled), all generated keys are lost.
   As a result, these unnecessary warnings are recorded in server's Event Log:

   ```
   No XML encryptor configured. Key {guid} may be persisted to storage in unencrypted form.
 
   Neither user profile nor HKLM registry available. Using an ephemeral key repository. Protected data will be unavailable when application exits.
 
   Using an in-memory repository. Keys will not be persisted to storage.

   The antiforgery token could not be decrypted.

   Error unprotecting the session cookie.

   The key {guid} was not found in the key ring.
   ```

   This way even if "Load User Profile" property is set to false, we will fix default ASP.NET behavior
   and avoid warnings spamming server's Event Log.