Expose ActivateSession service result (Good_PasswordChangeRequired) to client code

[e-lynch-theia]

### Problem Description
I am working with Eclipse Milo (currently 1.0.0 but thinking of moving to 1.1.2) and username/password authentication against an OPC UA server that may return Good_PasswordChangeRequired during ActivateSession.
Good_PasswordChangeRequired is a valid, successful StatusCode defined by the OPC UA specification to indicate that authentication succeeded but the user must change their password.
While Milo correctly handles this status internally and successfully activates the session, there does not appear to be any supported way for client application code to observe or react to this condition.

### What I’ve Observed
From debugging Milo client code:

Good_PasswordChangeRequired is returned only in the ActivateSessionResponse:
ActivateSessionResponse.getResponseHeader().getServiceResult()

In SessionFsmFactory.activateSession(...), this StatusCode is evaluated implicitly as “Good” and the FSM proceeds:
ctx.fireEvent(new Event.ActivateSessionSuccess(session));

At that point:

The ActivateSessionResponse is discarded
The service result is not stored on the OpcUaSession
No callback, listener, or hook is invoked

Higher‑level APIs such as:

OpcUaClient.connect()
SessionActivityListener
ServiceFaultListener
FSM Event.* classes

do not expose the authentication service result.

This makes it impossible for client applications to distinguish:

A “normal” successful login
A successful login that requires a password change

Why This Matters

From a client implementation perspective:

Good_PasswordChangeRequired is not an error, but it does require specific application behavior
The OPC UA specification does not provide a follow‑up status or persistent session state for this condition
As a result, the only point where this information exists is during ActivateSession
Without access to this signal, client applications cannot:

Prompt the user to change their password
Enforce password update policies
Trigger a SetPassword workflow deterministically

At the moment, the only deterministic solution appears to be patching Milo itself to capture the StatusCode inside SessionFsmFactory.activateSession(...).

Question / Request for Guidance

I would appreciate guidance on one of the following:

Is there an intended or supported way for client code to observe the ActivateSession service result (including advisory Good_* StatusCodes)?
If not, would it be reasonable to add one of the following in the future?

A client‑level callback / listener for ActivateSession results
Persistence of the activation StatusCode on OpcUaSession
An optional hook specifically for advisory authentication outcomes

[kevinherron]

Hmm, interesting. I'll have to think about this before I can give you a good answer.

Good_PasswordChangeRequired was introduced in 1.05, and it's the first time I'm aware of that a more specific Good service result would be reported, and it's unfortunate that it's happening a service that you don't actually call as a user because it's part of the SessionFsm.

[kevinherron]

I don't think there's any way to get this information right now, but it looks like there's a pretty easy path to making it available on the UaSession you get in the SessionActivityListener::onSessionActive callback as something like UaSession::getLastActivateSessionServiceResult returning Optional<StatusCode>.

It's not a general solution to all the service calls made by the Session FSM, but I'm not sure we really need that.

[e-lynch-theia]

Thanks for the clarification — that makes sense.
I agree that exposing the ActivateSession service result via the UaSession provided to SessionActivityListener::onSessionActive would be a clean and well‑scoped solution, and it fits nicely with the existing lifecycle model without exposing FSM internals.
Would this be something you’d consider adding to Milo in the future??
Even just having a lightweight, optional API like
UaSession::getLastActivateSessionServiceResult()
would make it possible for client applications to handle cases such as Good_PasswordChangeRequired deterministically, without changing existing behavior.

[kevinherron]

Yeah I’m gonna put up a PR for this today. It can be in the next release.

[e-lynch-theia]

That sounds great.
Just to help with planning on our side, do you have a rough idea when the next Milo release might be expected?
Even a broad timeframe (e.g. next minor release vs later this year) would be helpful.
Thanks again!

[kevinherron]

PR is up and ready to merge. I'll probably do a minor release in the next 2 weeks.

[e-lynch-theia]

That would be great Kevin. Thank you