auth followed by any action requiring auth fails

alunduil commented 5 years ago

I recently registered for hex.pm (I went through the web flow), and when I use rebar3 hex user auth it seems to work fine (I can see keys in hex.pm as well). When I attempt to do rebar3 hex user whoami I get the first set of failures below and when I try to do rebar3 hex publish I get the second set of failures below.

`rebar3 hex user whoami`

output: https://gist.github.com/alunduil/6324c19e288f581610201b05d386c2cf
stack trace: https://gist.github.com/alunduil/f866b7868eb6c0053dc383339b125bfe

`rebar3 hex publish`

output: https://gist.github.com/alunduil/0beadea6aeb350d9c8749a091af309ac

So, I try to auth again thinking it didn't hold and it succeeds and I now have duplicate keys on hex for my machine. Let me know what other information would be useful to discover why this isn't working as expected.

starbelly commented 5 years ago

What version of rebar_hex are you using? I see the latest version of rebar3 in use, so I'm hoping it's just that you need to ensure you're using at least rebar3_hex 6.5.0

alunduil commented 5 years ago

Sorry to disappoint: https://gist.github.com/alunduil/3f098145a9463bdbde9f5f0b0ccf40e7

starbelly commented 5 years ago

n/p, lemme see if I can replicate

starbelly commented 5 years ago

Alas I can not:

Username: ([])> starbelly
Account Password:
You have authenticated on Hex using your account password. However, Hex requires you to have a local password that applies only to this machine for security purposes. Please enter it.
Local Password:
Local Password (confirm):
Generating all keys...
 ~/d/e/jb_private123  rebar3 hex user whoami                                                                                                                   
starbelly (starbelly@somewhere.org)
 ~/d/e/jb_private123 rebar3 hex publish -r hexpm:jellybeam                                                                                                    
===> Verifying dependencies...
===> Using deprecated rebar_utils:vcs_vsn/3. Please upgrade your plugins.
Publishing jb_private123 0.1.0-rc322 to hexpm:jellybeam
  Description: An OTP library
  Dependencies:

  Included files:
    /Users/starbelly/devel/erlang/jb_private123/LICENSE
    /Users/starbelly/devel/erlang/jb_private123/README.md
    /Users/starbelly/devel/erlang/jb_private123/rebar.config
    /Users/starbelly/devel/erlang/jb_private123/rebar.lock
    /Users/starbelly/devel/erlang/jb_private123/src/ehttpd.erl
    /Users/starbelly/devel/erlang/jb_private123/src/jb_private123.erl
  Licenses: Apache 2.0
  Links:

  Build tools: rebar3
Before publishing, please read Hex CoC: https://hex.pm/policies/codeofconduct
Proceed? ("Y")> y
Local Password:
===> Published jb_private123 0.1.0-rc322

So things that could be potential problems on your end...

You have rebar3, hex_core, or rebar3_hex version cached somewhere that isn't in agreement and this could be for a variety of reasons. I do see that rebar3 isn't even able to make it to the point where it calls the provider (in this case rebar3_hex). Look in _builds or /path/to/rebar3. Sometimes it's easiest to back all this up, remove said files, and see if you can replicate by starting from scratch so to speak.
- Your hex.config (~/.config/rebar3/hex.config) is not in line with changes introduced with the latest rebar3_hex. Perhaps try backing up this file, removing it, and re-authenticating.
- There's something else causing this problem. I didn't ask what version of erlang you are using. If the above to possibilities do not pan, can you share that info and run rebar3 with debug on? env DEBUG=1 rebar3 hex user whoami

alunduil commented 5 years ago

Hmm, I removed all local configuration and started from a clean build and ended with the same issue I saw before.

I'm running this erlang:

erl: Erlang/OTP 21 [erts-10.2.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe] DEBUG=1 rebar3 hex user whoami: https://gist.github.com/alunduil/12bd1d8a30c3a51bd032bc7d8d95343f

In case it makes a difference I am overriding the REBAR_CACHE_DIR and I don't have a ~/.config/rebar3 directory (I'm keeping everything local to this project with envrc). I also install rebar3 into the project directly from a release; the one provided by NixOS is sandboxed too strictly right now.

I also grabbed a report in case that's helpful: https://gist.github.com/alunduil/882e21bd5b93edc9d34a1bf10ae3a22d

Thanks for helping me think through this one.

starbelly commented 5 years ago

Ahh ha! That is the issue. Now, let me try to find a work-around/fix. I have a few changes in master that would make this a more pleasant experience in terms of error messages, but they don't solve the problem. I'm pretty sure the config file problem will have to be addressed in rebar3, but let me find the fix before I start going off in that direction.

starbelly commented 5 years ago

@alunduil Ok, here is the work-around... rebar3 will assume that your hex.config is in $HOME/.config/rebar3... even if you are chrooted, etc. this should work, just tried on my machine.

So in a project I..

made a .config dir in the root of my project,
then rebar3 dir in that (or mkdir -p /path/to/project/.config/rebar3)
then moved my hex.config in there
finally I set $HOME to the root of the project.

Note: $HOME doesn't have to be your project dir, that's just what I did. It could be anywhere in your chroot. So long as $HOME contains .config/rebar3.

Hopefully, that's doable for you, we may want to introduce a new variable for this in rebar3.. not sure.

alunduil commented 5 years ago

Interesting. I wonder why when I set REBAR_CACHE_DIR that it puts my hex.config in that directory rather than HOME if it's only going to read it from HOME. That's highly counterintuitive. I'll see about setting HOME to be my direnv but I'm not sure what else that's going to screw up. It almost sounds like having an overloaded REBAR_CACHE_DIR is the antipattern here. I'll try it without that first.

starbelly commented 5 years ago

I agree, it should not put it into the cache dir. I'll look into this, discuss with some folks and do some PRs ASAP. Do let me know if this works for you 👍

alunduil commented 5 years ago

That sounds good. For now I'll drop my local REBAR_CACHE_DIR and see if I can get this working. Thanks for helping me figure out what was going on.

alunduil commented 5 years ago

@starbelly dropping the REBAR_CACHE_DIR worked like a charm. Once I auth'ed again whoami and publish worked like a charm. I'll keep my eye on this issue so I know when I can add back my local project cache.

starbelly commented 5 years ago

@alunduil See https://github.com/erlang/rebar3/pull/2060 Apparently there was a project config option we could have used in your config global_rebar_config_dir. This was not available as env var however and the PR I linked to adds that.

If you feel good on those two options can you close this issue?

alunduil commented 5 years ago

@starbelly that looks good to me, but I'm not clear on if I can set the global config dir separately from the cache dir. I'll try to grab the latest version and see if the setup I usually go for works as expected. Feel free to close this if you need to and haven't heard from me in a week though.

starbelly commented 5 years ago

It should. I think I may have to do another patch for REBAR_CACHE_DIR but the REBAR_GLOBAL_CONFIG_DIR env is respected.

alunduil commented 5 years ago

Excellent. I'll close this issue and if I notice anything further open another. Thanks for putting this fix together!

erlef / rebar3_hex

auth followed by any action requiring auth fails #113

`rebar3 hex user whoami`

`rebar3 hex publish`