Site Boot Flow

Injection Parsing

__SITE Injected? Y: use as model, store in appSettings
- N: __DOMAININFO injected? : Y: use siteId to fetch Site
  - N: use window.location to determine siteId

Determine domainInfo model from Window.location

At this stage we do not actually fetch the full item. We are constructing a hash that is roughly the shape of a domain record:

{
 siteId: '3ef'
 hostname: 'foo-dc.hub.arcgis.com',
 status: 200 | 403 | 404 | 500
}

Portal

Has window.loaction.hash? Y: create query from hash value
- N: assume "Hub Home" (aka /) and use portal-hub-home as the query param
- execute query & filter results
- Got Item? Y: construct domainInfo object with siteId
  - N: User auth'd? return status: 404 as user lacks rights to access the item
  - N: return object with status:403 as a site may exist, but just private

AGO

At AGO, all sites, private and public will have domain service entries

use window.location.hostname and call domain service
Got Entry? Y: return the domain info object w status: 200
- N: is hostname "hub-homeish"? Y: construct a domain object using the well-known item id for the env, status: 200
  - N: return status: 404 as no known site exists for this domain

Getting the actual Site Object, given a domainInfo hash

At this point we should know if a site item exists or not. We just need to try to fetch it via the Site Service so that various migrations are applied on the fly.

Got site item via site-service? Y: use as the model
- N: Is this a Hub-Home request? Y: use the default hub-home item
- N: Is user auth'd? Y: set status:404 because no site item exists
  - N: set status: 403 so we force auth

Render Cycle

At this point we inspect the model and decide what template to render

If status: 200, render the site
if status: 403, render the sign-in template
if status: 404, render site does not exist
if status: 500, render server error template and send telemetry

403 Auth --> Application::Route::GatewaySignin

this is more convouted, but basically kick off the auth process, and when that completes, we use the domainInfo object to call the siteFetch code again, but with an additional flag so that that process knows that the user is now authenticated, and and failure to fetch it at this point really means they simply do not have access, so we don't show the same 403 screen.

dbouwman/Site-Boot-Flow.md