Skip to content

WIP: CF SDK: Modified SignalWire Client with auth states #1192

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 32 commits into
base: main
Choose a base branch
from

Conversation

iAmmar7
Copy link
Member

@iAmmar7 iAmmar7 commented Mar 21, 2025

Description

  • Introduce a new SignalWireV4 (beta) client with two new props:
    • authState: Used for session reconnect and/or call reattach.
    • onAuthStateChange: Callback trigger every time the auth state changes.
  • Removed the implicit WebSocket reconnect/reauth from the new SDK client.

Type of change

  • Internal refactoring
  • Bug fix (bugfix - non-breaking)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Code snippets

In case of new feature or breaking changes, please include code snippets.

Copy link

changeset-bot bot commented Mar 21, 2025

⚠️ No Changeset found

Latest commit: 5b5df3f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

/**
* SAT Session is for the Call Fabric SDK
*/
export class SATSessionV4 extends BaseJWTSession {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did understand why we need this new SATSessionV4 class...
Why is it extending BaseJWTSession and not SATSession or even JWTSession?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see the definition of JWTSession. We no longer need any of those implementations such as state persisting, socket close cleanup, etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can even remove the BaseJWTSession and directly extends from BaseSession. The only thing I need from the BaseJWTSession is the this.expired getter while calling the reauthenticate API.

public agent = process.env.SDK_PKG_AGENT!

constructor(public options: SATSessionOptions) {
let decodedJwt: JWTHeader = {}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can remove all this if you extend the SATSession

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can not extend SATSession either since the new SATSessionV4 does not need to extend from JWTSession.

* Authenticate with the SignalWire Network using SAT
* @return Promise<void>
*/
override async authenticate() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is the only logic different from the SATSession.
Why not implement it on the SATSession?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from this, we also do not need to override _checkTokenExpiration in the new SATSessionV4.

Similarly, the old SATSession inherits from JWTSession which has all those logic to persist the states, that does not require in the new SATSessionV4.

Copy link
Collaborator

@jpsantosbh jpsantosbh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good in general,
I think you should either not create a new SATSessionV4, but if you prefer to have the custom authorize in specific class that class should extend the SATSession.

I liked the proposed new interface, but I'm not sure about having the v4 on it, but I'll defer to Product and DevEx Team on that.

@iAmmar7
Copy link
Member Author

iAmmar7 commented Apr 9, 2025

Refactor logic has been moved to this PR: #1200

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants