getSession() call doesn't seem to update useSession()

[atawfique21]

I'm trying to update the session when a user changes username with a button click.

From research done, I've learned that: I must use Database with JWT turned off as you mentioned:

When using JWT, the data is stored in a cookie, and you have to trigger the sign-in flow again to get the new user data.

What I am trying to achieve now is mentioned in #2269:

If you use a database, you can update the data directly, and if you configured it correctly, I believe the getSession call should update it already.

Currently, I have an API call. When the button is clicked, I update a custom column in the users table generated by next-auth. I have updated the model so all of this works.

import { useSession, getSession } from 'next-auth/client'
import axios from "axios"


function newUser() {
  let [session, loading] = useSession()

  const handleUpdate = async () => {
    console.log(session) // this returns the session where session.user.custom_username is old value
    axios.get('http://localhost:3000/api/update-username').then(async () => {
      console.log(await getSession()) // this returns the session where session.user.custom_username is new value
    })
  }

  return (
    <div>
      <p>Hi there, you are new around here</p>
      <button onClick={() => handleUpdate()}>change username</button>
      <h1>{session && session.user.custom_username}</h1>
      {/* No matter what, session.user.custom_username always remains the same until I refresh the page */}
    </div>
  )
}

export default newUser;

I understand that I can force the page to refresh with Router but I'm ideally looking for a way to update Session in this component when this Axios call is completed.

So far:

• On page load, session.user.custom_username shows current DB value
• On button click, axios updates the custom username in the backend
• In the .then() part of the Axios call, getSession() returns the new custom_username value as part of the session
• Session is updated for newUser() component and the <h1> changes it's value appropriately.

Please let me know what I'm missing or doing wrong.
Thanks for your work and time.

[atawfique21]

I believe I'm come to a bit of a workaround.
This workaround consists of ditching useSession() as I can't find a way to update the session value inside of it and instead using getSession() to set a state value using useEffect()

Can anyone let me know if this is the best way to approach this problem?

import { getSession } from 'next-auth/client'
import { useEffect, useState } from 'react'
import axios from "axios"


function newUser() {
  let [realSession, setRealSession] = useState()

  useEffect(() => {
    async function fetch() {
      let session = await getSession()
      setRealSession(session)
    }

    fetch()
  }, [])

  const handleUpdate = async () => {
    axios.get('http://localhost:3000/api/update-username').then(async () => {
      let newSession = await getSession()
      setRealSession(newSession)
    })
  }

  return (
    <div>
      <p>Hi there, you are new around here</p>
      <button onClick={() => handleUpdate()}>change username</button>
      <h1>{realSession && realSession.user. custom_username}</h1>
    </div>
  )
}

export default newUser;

[balazsorban44]

Thank you for opening this discussion! 🙏

I actually don't understand why people are tripping on this. 😕

When getSession is called client-side, it is supposed to send a message that should re-trigger the session fetching in useSession:

next-auth/src/client/index.js

Lines 161 to 167 in 2155c93

	export async function getSession(ctx) {
	const session = await _fetchData("session", ctx)
	if (ctx?.triggerEvent ?? true) {
	broadcast.post({ event: "session", data: { trigger: "getSession" } })
	}
	return session
	}

next-auth/src/client/index.js

Lines 82 to 159 in 2155c93

	export function useSession(session) {
	const context = useContext(SessionContext)
	if (context) return context
	return _useSessionHook(session)
	}
	function _useSessionHook(session) {
	const [data, setData] = useState(session)
	const [loading, setLoading] = useState(!data)
	useEffect(() => {
	__NEXTAUTH._getSession = async ({ event = null } = {}) => {
	try {
	const triggredByEvent = event !== null
	const triggeredByStorageEvent = event === "storage"
	const clientMaxAge = __NEXTAUTH.clientMaxAge
	const clientLastSync = parseInt(__NEXTAUTH._clientLastSync)
	const currentTime = _now()
	const clientSession = __NEXTAUTH._clientSession
	// Updates triggered by a storage event *always* trigger an update and we
	// always update if we don't have any value for the current session state.
	if (!triggeredByStorageEvent && clientSession !== undefined) {
	if (clientMaxAge === 0 && triggredByEvent !== true) {
	// If there is no time defined for when a session should be considered
	// stale, then it's okay to use the value we have until an event is
	// triggered which updates it.
	return
	} else if (clientMaxAge > 0 && clientSession === null) {
	// If the client doesn't have a session then we don't need to call
	// the server to check if it does (if they have signed in via another
	// tab or window that will come through as a triggeredByStorageEvent
	// event and will skip this logic)
	return
	} else if (
	clientMaxAge > 0 &&
	currentTime < clientLastSync + clientMaxAge
	) {
	// If the session freshness is within clientMaxAge then don't request
	// it again on this call (avoids too many invokations).
	return
	}
	}
	if (clientSession === undefined) {
	__NEXTAUTH._clientSession = null
	}
	// Update clientLastSync before making response to avoid repeated
	// invokations that would otherwise be triggered while we are still
	// waiting for a response.
	__NEXTAUTH._clientLastSync = _now()
	// If this call was invoked via a storage event (i.e. another window) then
	// tell getSession not to trigger an event when it calls to avoid an
	// infinate loop.
	const newClientSessionData = await getSession({
	triggerEvent: !triggeredByStorageEvent,
	})
	// Save session state internally, just so we can track that we've checked
	// if a session exists at least once.
	__NEXTAUTH._clientSession = newClientSessionData
	setData(newClientSessionData)
	setLoading(false)
	} catch (error) {
	logger.error("CLIENT_USE_SESSION_ERROR", error)
	setLoading(false)
	}
	}
	__NEXTAUTH._getSession()
	})
	return [data, loading]
	}

Granted, the current solution is not really elegant and ignores some basic React rules, I am not surprised if we have a weird bug that makes this not work... Hopefully, the new version of the client code that is more React oriented will be more stable in this manner.

Have a glimpse at it here: https://github.com/nextauthjs/next-auth/blob/next/src/client/react.js

I still hope an update method or similar exposed on useSession will make the most sense here, but I am open to suggestions for an alternative API in #2269

[atawfique21]

To be honest, I think this is a shortcoming of next-auth for the time being. We really do need a robust method to deal with users changing their attributes like usernames, profile pictures, etc. And upon those attributes changing, sending the session token down the prop line to be re-rendered by React. In my 12+ hour hunt, I've seen countless discussions/issue tickets + stackOverflow questions and all of the solutions (including my solutions!), in my opinion, are very hacky and defeat optimization benefits next-auth otherwise provides.

I certainly think your solution of an update method on useSession is the way to go. This allows for fine-tuning and users like me would be able to ditch the aforementioned broadcast not working. Of course, when using update, I would expect all components that are using useSession to get the new session object for no-refresh rendering.

For the time being, I'm thinking the best approach is to use React Router and refresh the page upon submit and forgo my 'workaround' where I ditch useSession() for getSession(). I come to this because my <Header> component contains a reference to the user's custom username and that component would also need to forgo useSession() for getSession(). And on top of that, I'm not even sure how to force <Header> to re-render when <newUser> is the one that submits these changes. It seems like when updating user attributes client-side, for the time being, a page refresh is just the way to go. Do you agree with this sentiment or perhaps you have a better way of approaching this while we wait for #2269 to be coded & merged?

On the bright side: At least a page refresh would only need to occur only when user something about their profile, which isn't very often in my application.