AccessToken Store & Non-Interactive Authentication

[cseitz]

• A combined getter/setter can be used in place of accessToken to save and retrieve the token.
• The authenticate procedure no longer uses readline to wait for user input, but instead attempts to authenticate every second until it works.
  • Definitely making unnecessary requests, but does it even matter considering we're talking to a device on our own network?

I tried to keep the program behavior the same. My changes only take place if the accessToken store is specified.

• You can still npx dirigera authenticate, but now its unnecessary because the program will prompt you to press the button and temporarily cease execution till you do so. From that point forward, your store will save the token and any future runs of the program will simply pull it from wherever you desire.

const client = createDirigeraClient({
    gatewayIP: '0.0.0.0',
    accessToken: async (accessToken) => {
        const file = 'token.txt';
        if (accessToken) {
            await writeFile(file, accessToken)
        }
        try {
            return await readFile(file, 'utf8');
        } catch (err) {
            return null;
        }
    },
})

[lpgera]

Hey @cseitz and welcome to the repository! Congrats on being the first collaborator to my project! 🎉

• A combined getter/setter can be used in place of accessToken to save and retrieve the token.

This is a brilliant idea!

• The authenticate procedure no longer uses readline to wait for user input, but instead attempts to authenticate every second until it works.

  • Definitely making unnecessary requests, but does it even matter considering we're talking to a device on our own network?

I don't think the requests should cause any issues, but I left some comments on your suggested changes. Some testing with the gateway will also be needed before I can merge to avoid any lockups or bans from the gateway.

• You can still npx dirigera authenticate, but now its unnecessary because the program will prompt you to press the button and temporarily cease execution till you do so.

While this is true, I'd like to keep supporting use cases in which the library users provide the token from an environment variable such as in a Docker container. Which is still okay with your implementation, but I just wanted to highlight that there are different approaches to keep in our minds.

I'm excited to continue working with you to get this PR merged!

[zinen]

I really need this to support non-Interactive authentication. And also support the idea of continuously pull status from while waiting for the push of the button.

When will this get merged?

[zinen]

Any updates on this PR?

[lpgera]

Sorry, but I've been focusing much more on covering the available gateway functionalities and providing better typings for the existing features. Which is still lacking in many places at the moment, such as the websocket events.

However, I'd like to understand your need better @zinen. If the authenticate() method had a version which wouldn't require input on stdin, but it'd rather perform a polling (with a sensible timeout), would that be working for you?

[zinen]

I would say yes to that. My case is that i wanna include this module inside another system. The system support timeout and event emitters. But no access to console must be required. All info/returned text must be piped back to the app via yielded info from a async job or callback.

[lpgera]

Authentication works without console input starting from version 0.13.0.