Remove access to keychain about apm HOT 17 CLOSED

Unfortunately we need the token to publish.

I think we should leave the keychain stuff in there for now and revisit this when it's public. The issues yesterday were entirely related to atom/atom@b449bb4.

from apm.

They werent related to that issue. That issue was the spark to my working on apm. I was adding something in for #33 (see #34), and was using keytar.

from apm.

But isn't that token only needed to access Atom.io? Using a hardcoded token would solve the same problem.

I don't think we have to do this before we launch the Alpha. But we will run into problems if an alpha user tries to use APM before they log into GitHub from Atom.

from apm.

Note: logging into github via atom still creates a different key in the keychain than apm uses (github.com vs GitHub API Token). I was going to unify them, but that was the beginning of the rabbit hole that lead to #34.

from apm.

@benogle ahh, right. Now this is all coming back to me.

Rather than hardcode this now, let me see if I can come up with a way to solve the npm vs atom npm split so that it would be possible to merge #34.

from apm.

I know I voiced this yesterday, but on the topic of splitting out apm:

apm should be treated as a binary, not as some dependency. Nothing import/requires it. So it can be totally separate from atom/atom with it's own node_modules and everything. This is different than the grunt issue cheng was having, as he wanted to import in 2 different contexts. Maybe apm is even npm installed globally? I dunno, but it is not necessary to install it into atom/atom's modules.

from apm.

What are the advantages of using the keychain over using a hardcoded token?

from apm.

The advantage in my mind for using individual tokens is that we know which github user publishes if they each use their own oauth token (so we can do proper authorization).

@benogle I'll definitely investigate that.

from apm.

Even though apm is only used as a binary right now, the goal was to extract the package manager classes from atom/atom to atom/apm to reduce the duplication between the two and so atom would require things directly from apm and so apm would need to be in node_modules.

from apm.

Here is my idea on how to separate authorization from APM. I'll use apm publish as the example.

I make changes to wrap-guide and want to publish them. The cli command is exactly the same apm publish minor. But under the hood things will be different. Instead of Atom.io creating the tag, APM will create the tag:

1. APM will figure out what the next minor version is.
2. APM will call git tag -a $NEXT_VERSION
3. APM will push the tag (as it does now).
4. (possibly optional) APM will tell Atom.io to use $NEXT_VERSION as the current version.

Step 4 is optional because I think @thedaniel has some service hook magic which will automatically update Atom.io when a new tag is pushed to an Atom package.

This gets APM out of the authorization game entirely*. No token needed!

*Not entirely, if you don't have push access to the repository we will need to output the error and explain that to the user.

from apm.

Not sure I understand, apm currently creates the tag.

from apm.

Also, wouldn't apm still need authorization for things like apm install and apm available?

from apm.

It would need authorization, but only because Atom.io and the Atom org are temporarily private. I doesn't gain anything from using a user's personal token.

from apm.

I'm down with hardcoding the token if we remove the authenticated request that apm makes to atom.io when publishing. @thedaniel is it possible to update things to follow @probablycorey's proposed flow?

from apm.

The advantage in my mind for using individual tokens is that we know which github user publishes if they each use their own oauth token (so we can do proper authorization).

This is correct - we also use the token to fetch the package metadata (package.json and readme) for a repository - if we use a token for e.g. atom-bot for everyone, we would need a hard requirement that packages be in public repos. This is unlikely to be something we can do until the public release - is it something we want to do after that?

It would need authorization, but only because Atom.io and the Atom org are temporarily private. I doesn't gain anything from using a user's personal token.

We still probably want to prevent person A from publishing person B's packages to the index - maybe you're working on something in a public repo and you don't want it in the index yet for whatever reason, but if there's no authorization I can just tell apm your repo name and it will be pulled in to atom.io. Another interesting problem without individual auth is how to handle unpublishing versions and packages - there are hooks now that create new versions when a Release is created, but I don't think there's an event for when a Release is deleted.

I'm not against trying to make it work, but using individual tokens is convenient for a couple reasons so let's figure it out in that context.

from apm.

One possibility for ensuring the user token is present that @probablycorey and I discussed at lunch is APM checking for the token, and if it is not found, launching Atom with a flag like atom --sign-in or atom --command github-sign-in, so the user could sign in with that dialog and store the token.

from apm.

Closing this out, apm now has a login command, and also atom/atom now builds with two versions of apm included, one compiled against node's headers and one compiled against atom's headers.

from apm.