docs: reduce operational complexity of enabling auth state

docs/hub-deployment-guide/configure-auth/github-orgs.md

@@ -134,39 +134,37 @@ Once you have confirmed with the Community Representative that users can login,
 
 ## Restricting user profiles based on GitHub Team Membership
 
-JupyterHub has support for using [profileList](https://zero-to-jupyterhub.readthedocs.io/en/latest/jupyterhub/customizing/user-environment.html#using-multiple-profiles-to-let-users-select-their-environment)
+KubeSpawner supports using [profileList](https://zero-to-jupyterhub.readthedocs.io/en/latest/jupyterhub/customizing/user-environment.html#using-multiple-profiles-to-let-users-select-their-environment)
 to give users a choice of machine sizes and images to choose from when launching their
 server.
 
 In addition, we can allow people access to specific profiles based on their GitHub Teams membership!
 This only works if the hub is already set to allow people only from certain GitHub organizations
 to log in. See [](howto:features:profile-restrict) for more information.
+
 ### Enabling team based access on hub with pre-existing users
 
-If this is being enabled for users on a hub with *pre-existing* users, they
-will all need to be logged out before deployment. This would force them to
-re-login next time, and that will set `auth_state` properly so we can filter
-based on team membership - without that, we won't know which teams the user
-belongs to, and they will get an opaque 'Access denied' error.
+Users already logged in to JupyterHub needs to be forced a re-login for access
+to `/hub` paths, otherwise they may be presented with too few server options or
+an opaque 'Access denied' error when visiting `/hub/spawn`.
+
+Forcing users to re-login to JupyterHub isn't influencing users access to
+running servers at `/user/my-username`, it will just lead to a quick restart of
+the `hub` pod, also without disrupting the `proxy` pod.
 
-1. Check with the community to know *when* is a good time to log everyone
-   out. If users have running servers, they will need to refresh the page -
-   which will put them through the authentication flow again. It's best to
-   do this at a time when minimal or no users are running, to minimize
-   disruption.
+By doing the following steps, pre-existing users should see the server profiles
+they have access to:
 
-2. We log everyone out by regenerating [hub.cookieSecret](https://z2jh.jupyter.org/en/stable/resources/reference.html#hub-cookiesecret).
-   The easiest way to do this is to simply delete the kubernetes secret
-   named `hub` in the namespace of the hub, and then do a deployment. So
-   once the PR for deployment is ready, run the following command:
+1. Force a re-login on next `hub` pod restart by deleting an auto-generated
+   cookie secret for JupyterHub ([`hub.cookieSecret`](https://z2jh.jupyter.org/en/stable/resources/reference.html#hub-cookiesecret))
+   stored in a k8s secret under a specific key-value pair.
 
    ```bash
-   # Get kubectl access to the cluster
    deployer use-cluster-credentials <cluster-name>
-   kubectl -n <hub-name> delete secret hub
+   kubectl patch secret hub -n <hub-name> --type=json -p='[{"op": "remove", "path": "/data/hub.config.JupyterHub.cookie_secret"}]'
    ```
 
-   After that, you can deploy either manually or by merging your PR.
+2. Either deploy manually or merge your PR.
 
-This should log everyone out, and when they log in, they should see
-the profiles they have access to!
+   A new cookie secret will be auto-generated by the JupyterHub chart now and
+   the `hub` pod will restart, forcing users to login again.