I guess what I don’t understand is how are sessions “pinned” to the IP address
That’s OK. I’ll try to explain:
When a registered user logs in, Shield generates a cryptographically secure random token, salts and hashes it. The token digest is saved to the database, along with the IP address of the user who just logged in, and some other details.
After a successful database save, Shield stores the ID of the database entry, and the raw token, in the user’s session.
When a user tries to access a route that requires login, Shield checks their session for an ID and token that matches a corresponding ID and token digest in the database.
If a valid match is found (and the pin-login-to-ip feature is disabled), they are allowed access to the route. Otherwise, access is denied.
If a valid match is found, and the pin-login-to-ip feature is enabled (it is, by default), the client’s current IP address is compared with the IP address that was previously saved to the database after successful login.
If they 2 IPs match, access is granted. Otherwise, access is denied.
If another user on the same IP requests a new session cookie, are both sessions valid or will the new session override the other pre-existing session?
Sessions are unique to a client. So 2 different users get 2 different, separate sessions. Even the same user on 2 different browsers get 2 different, independent session cookies on each browser. Same IP or not does not matter. Sessions are not tied to the IP address.
Is it ever possible to recover a pre-existing session if you have access to the IP address?
No. You must have access to the same client/browser (or steal the cookies via some other means). Then, if the session has not expired, you may be able to use it.
If the pin-login-to-ip feature is disabled, you may be able to use the stolen cookies right away.
If it is enabled, Shield would perform an extra check that your current IP address matches the IP address in the database.
Hope this helps?