Skip to content

Check whether a page is authorized

Answers whether a requested page is authorized for the current user by testing membership in the resolved authorized-item set purely in memory — no database access.

Field Value
Operation ID OP-MENU-02
Trigger clsControllerBase.RedirectUnauthorizedUsers on every web request, via NavigationContext.IsMenuItem
Inputs Application code, requested page link
Outputs The matching clsMenuAuthorizedItem, or Nothing (interpreted as "not authorized")
Primary components clsMenuAuthorizedItemCollection.FindPage(inAppCode, inPageLink)
Entry point SAIF.Business.Menu/clsMenuAuthorizedItemCollection.vb

Steps

  1. Filter the in-memory collection with a predicate: ApplicationCode equals the supplied code (case-sensitive, exact) and LinkOnly(PageLink.Trim.ToUpper) = LinkOnly(inPageLink.Trim.ToUpper). (BR-MENU-008, BR-MENU-009)
  2. LinkOnly strips everything from the first ? onward, so query-string variants of the same page resolve to the same grant. (BR-MENU-009)
  3. Move matches into a new collection via mdlUtilities.AddToList.
  4. Return the first match, or Nothing when none. (BR-MENU-008)
  5. If no match: the caller treats Nothing as denial and redirects the request.
  6. FindPageExact performs the same steps without LinkOnly, requiring the query string to match too.

Process flow

flowchart TD
    Start([Web request received]) --> Filter[Filter authorized items: ApplicationCode + LinkOnly page match]
    Filter --> Found{Match found?}
    Found -->|Yes| Allow([Return matching item, allow request])
    Found -->|No| Deny([Return Nothing, redirect unauthorized user])

Failure and edge-case behavior

  • No match found: the caller receives Nothing and treats the request as unauthorized.
  • FindPageExact requires the full page link (including query string) to match, so a parameterized request that does not exactly match the stored grant is denied even if FindPage would allow it.

Sources

  • SAIF.Business.Menu/clsMenuAuthorizedItemCollection.vb