(WEB_PORTAL) Showing Different Features Based on the User's Network Location

Overview

This service is designed so that the set of available features differs depending on whether a user connects from the internal network or from outside it. Rather than making that determination once on the server and stopping there, we improved the UX so users can immediately understand, right on the screen, why a given feature is unavailable to them right now.

Key Implementation Points

1. Network Location Lookup API

We built a dedicated lookup API that returns whether the current request came from the internal network or from outside it, along with the IP information used to make that determination. The frontend calls this API to figure out the current status.

2. Network Status Hook

Since multiple components needed to repeatedly check the network location, we extracted this lookup logic into a reusable hook.

useNetworkCheck():
    state = { isInternalNetwork, isLoading }
    On mount, call the network location lookup API → update state
    return state

3. Disabled Buttons with a Guidance Badge

For buttons that trigger actions only allowed on the internal network, we disabled the click itself when an external connection was detected, and displayed a guidance badge next to it saying something like "Available only from the internal network." The server was already performing the same validation, but we judged that blocking the action on the client side beforehand gives users a much clearer experience than letting them try and then get rejected.

Retrospective

• Access control ultimately has to be enforced on the server, but from a UX standpoint, we found that telling users right on the screen "why" something isn't allowed builds trust. This reaffirmed for us that server-side validation and client-side guidance aren't substitutes for each other — they're complementary, each playing a different role.