"400: Invalid request parameters" when signing in

I'm getting the following when executing op <account>.1password.com <email> <secret>, then after inputting my password at the prompt:

[LOG] 2017/10/25 21:03:24 (ERROR) 400: Invalid request parameters.

What does this mean? --verbose doesn't display any extra detail.


1Password Version: 0.1.1
Extension Version: Not Provided
OS Version: Ubuntu 17.10
Sync Type: Families
Referrer: forum-search:400: Invalid request parameters.

Comments

  • rickfillionrickfillion Junior Member

    AgileBits Team Member

    That usually means either the secret key or master password are incorrect. The command you quoted seems to lack “signin” and the secret key. Are those there when you’re using it? I’d think so since you’re getting prompted for a password, but it’s worth checking.

    Rick

  • Hi Rick,

    Yep, sorry for that omission - signin was in my command. Will check my creds and try again.

    In the meantime, would it make sense to use a different HTTP error code here to indicate invalid creds? 400 would imply op's request to the server has bad syntax; 401 might be more applicable.

  • I've just tried again with the same key and I've logged in without a hitch. I tried re-entering my password several times before. Perhaps there was a problem accessing the server yesterday?

  • rickfillionrickfillion Junior Member

    AgileBits Team Member

    The server is supposed to return 401 in that case. We’ve had a bit of trouble figuring out what causes the CLI app to get 400 returned in some but not all cases. I’ve seen it myself, but not reliably. Which makes tracking it down a little tricky. Definitely something I want us to fix.

    Rick

  • rickfillionrickfillion Junior Member

    AgileBits Team Member

    I found the case where we return 400 instead of 401. Gonna try to get that fixed up for us.

    Thank you for reporting this.

    Rick

  • I had the same problem and tried a little bit of debugging. I tried a few different passwords and the errors seems to appear when the password starts with the character "§".

  • rickfillionrickfillion Junior Member

    AgileBits Team Member

    @sven_nexiles : hrmm... that shouldn't matter.

    Try again now. We've just pushed a new build of our server which has what I believe to be the code fix for this.

    Rick

  • rickfillionrickfillion Junior Member

    AgileBits Team Member

    @sven_nexiles : if you still see the issue when the password starts with that char, let me know and I'll dig into it.

    Rick

  • rickfillionrickfillion Junior Member

    AgileBits Team Member

    I tried to reproduce an error with a password that begins with § and was unable to find an issue.

    Rick

  • Hi Rick, sorry i can still create that error.
    I also had some trouble with the json output and the default encoding of the powershell yesterday.
    Using these two magic lines helped me out there but unfortunatly does not help on the master password problem.

    $OutputEncoding = New-Object -typename System.Text.UTF8Encoding
    [Console]::OutputEncoding = New-Object -typename System.Text.UTF8Encoding

    My Powershell Version running on latest Windows 10 Pro

    Name Value
    ---- -----
    PSVersion 5.1.16299.64
    PSEdition Desktop
    PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
    BuildVersion 10.0.16299.64
    CLRVersion 4.0.30319.42000
    WSManStackVersion 3.0
    PSRemotingProtocolVersion 2.3

    SerializationVersion 1.1.0.1

    Sven

  • rickfillionrickfillion Junior Member

    AgileBits Team Member

    Thanks for the update @sven_nexiles.

    We'll try to take a look at what's going on in powershell there. Here on my Mac with Terminal.app + bash it works fine.

    Rick

  • rickfillionrickfillion Junior Member

    AgileBits Team Member

    Hi @sven_nexiles,

    We've been able to reproduce the issue. The § character nearly everywhere is encoded as 0xC2A7, but it seems that in Windows on the command line it's coming in as 0x15. The same character can indeed be encoded in multiple different ways, and that's something we take into consideration with Master Passwords, as it's a common issue when using keyboards with different languages. And so we use string normalization to convert different encodings into a normal form which will be the same regardless of original encoding. But it seems like in this case the normalization isn't wanting to acknowledge that 0x15 is equivalent to 0xC2A7.

    We're going to keep poking around to learn more about this problem, but we're going to be a little limited about what we can actually do about this issue.

    Rick

Leave a Comment