Skip to content
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

Figure out a better auth file structure for future extensibility #567

Open
vladfrangu opened this issue May 13, 2024 · 0 comments
Open

Figure out a better auth file structure for future extensibility #567

vladfrangu opened this issue May 13, 2024 · 0 comments
Labels
help wanted Extra attention is needed. low priority Low priority issues to be done eventually.

Comments

@vladfrangu
Copy link
Member

The current structure for our auth.json file, alongside it's code, is quite a mess...

{
        "token": "you wish you knew >:3",
        "id": "oyHxoiAZ4rPx2RPK6",
        "username": "vladfrangu_apify",
        "profile": { ... },
        "email": "[email protected]",
        "proxy": {
                "password": "nop, not here either, keep looking",
                "groups": [ ... ]
        },
        "plan": { ... },
        "effectivePlatformFeatures": { ... },
        "createdAt": "2021-03-27T22:27:56.809Z",
        "isPaying": false
}

Not only does this file format not support multi-auth at all (which is something we want in the future to allow you to call/push actors from/to an organization account), it also stores a lot of information that the CLI realistically doesn't need or use.

What should be done

I'd personally see this as a multi-step process

Figure out a new structure for the file

I'd leave this up to the person implementing this how they want to do it. Here's two examples I can think off

// Alias for clarity
type UserId = string;

export type AuthFile = Record<UserId, Data>;
// or
export type AuthFile = ({ userId: UserId; } & Data)[];
// or some other type you may find makes best sense in this case

The format needs to support storing between 0 and n user/organizations and their tokens.

Figure out what data we actually need to store vs data we can/should just fetch on demand and cache at runtime

Token is mandatory for...obvious reasons.
Username is a maybe, since it'd be a cached value that doesn't get updated if you rename yourself on the console (feature request? :D)
Profile? Email? Plan? Probably not something we need to cache all the time, but something we can fetch if we really need it for a command
Proxy? Probably need it for apify run only.

Write the code assuming you have no existing auth file at all, and test it out with 1-user auth and with multi-auth

More less the easiest part once first two tasks are done. Whoever is implementing this can just start with a "blank" slate. You might need to adjust some things (specifically test hooks) for which you can/should ping me if you need guidance. You should also adjust the whois command to print out all logged in accounts

TL;DR: Assume you are a logged out user and you call apify login for the very first time. Code should focus on logging in, then storing the data correctly.
Then try logging in with another account.
Then see what whois prints out
Then try logging out from one of the accounts.

Write code to migrate the old structure to the new one

This ideally can be an oclif hook (possibly prerun, with checking which cmd is ran, or just in general). This also needs testing, which may be harder to achieve, so definitely feel free to ping for help. Ideally we should have some way to detect if the file is in old format versus the new format (version field or similar)

Open the PR

???

profit

@vladfrangu vladfrangu added help wanted Extra attention is needed. low priority Low priority issues to be done eventually. labels May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed. low priority Low priority issues to be done eventually.
Projects
None yet
Development

No branches or pull requests

1 participant