"400: Invalid request parameters" when signing in

snoopdouglas
snoopdouglas
Community Member

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

  • 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

  • snoopdouglas
    snoopdouglas
    Community Member

    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.

  • snoopdouglas
    snoopdouglas
    Community Member

    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?

  • 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

  • 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

  • sven_nexiles
    sven_nexiles
    Community Member

    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 "§".

  • @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

  • @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

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

    Rick

  • sven_nexiles
    sven_nexiles
    Community Member

    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

  • 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

  • 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

  • sven_nexiles
    sven_nexiles
    Community Member

    Hi Rick,

    encodings and dateformats keeps developers up at night, no matter what field you are in ;-)

    My colleague just had the same issue with "_" character. "!" seems to work, maybe because it's in the 0x2* of the ASCII Table who knows...
    What's also interesting is that it seemed to work from cmd but not in the powershell in that case, at least for the signin thing.

    Anyhow, we have a workaround for now, which is enough to keep working with this awesome tool. So thank you for that!

    Sven

  • AGAlumB
    AGAlumB
    1Password Alumni

    encodings and dateformats keeps developers up at night, no matter what field you are in ;-)

    @sven_nexiles: I don't know whether to laugh or cry. Maybe both... :lol: :cry:

    Interesting observation about the characters. Glad that workaround helps in the mean time. Cheers! :)

  • Thanks for the update @sven_nexiles. I'm a little mad that you've found another character that doesn't work right. Both _ and ! should be very standard ASCII characters, so it really surprises me that _ is giving you grief.

    The great thing about standards is that there's so many to choose from. :P

    Rick

    P.S. don't get me started on date formats.

This discussion has been closed.