"400: Invalid request parameters" when signing in

snoopdouglas

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.

rickfillion

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

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

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?

rickfillion

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

rickfillion

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

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

rickfillion

@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

rickfillion

@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

rickfillion

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

Rick

sven_nexiles

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

rickfillion

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

rickfillion

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

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

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! :)

rickfillion

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.