Hacker News new | ask | show | jobs
by legitimate_key 123 days ago
Thanks for the Mockaton suggestion! I like the API mocking approach - that handles the backend data cleanly.

The challenge I kept running into was the frontend side during live screen shares. Even with mocked APIs, I'd have credentials visible in browser tabs, notifications popping up with client names, or sidebar elements showing sensitive info.

Did you find Mockaton solved the full screen-share exposure problem, or did you combine it with other approaches?

1 comments

I’d need more details, but here are few guesses:

1. If Frontend is directly fetching from a third-party API. Maybe, you could add an env var with the base URL, so it points to the mock server.

2. If it’s a third-party auth service

2a. If the auth service sets a cookie with a JWT, you could inject that cookie with Mockaton like this: https://github.com/ericfortis/mockaton/blob/354d97d6ea42088b...

2b. If it doesn't set a cookie (some SSO providers set it in `sessionStorage`), and assuming it’s a React app with an <AuthProvider>, you might need to refactor the entry component (<App/>) so you can bypass it. e.g.:

  SKIP_AUTH // env var
   ? <MyApp/> 
   : <AuthProvider><MyApp/></AuthProvider>
Then, instead of using the 3rd party hook directly (e.g., useAuth). Create a custom hook, that fallbacks to a mocked obj when there's no AuthContext. Something like:

  function useUser() {
    const context = useContext(AuthContext)

    if (!context) 
      return {
       id_token: 'aa',
       profile: { name: 'John' }
      }

    return {
      id_token: context.id_token ?? '',
      profile: context.profile ?? {},
    } 
  }