I've just checked to ensure I can successfully authenticate using my credentials. Are you able to login to the website using the email and password with which you are authenticating?
I'm having trouble figuring out what's going on without being able to reproduce it. What happens if you
reset the password for the account?
create a new account and attempt to authenticate with it?
We did have a recent release that could possibly be related to the trouble you're having, but I don't know what could have caused a sudden inability to authenticate an existing account.
You're right, there was a release last week that involved a fair amount of account-related code. I'm talking with that team and trying to figure out what could be going on. I'll update you guys as soon as I find something out.
the call will be redirected, and in the process (depending on your HTTP library) you'll likely be dropping the POST data and performing a GET on the new URL. This is not new behavior, however, so I'm not banking on that being the problem. I just wanted to make the suggestion in case it is.
Just to rule out the possibility that there is something wrong with the request, could you try hitting the authenticator.php endpoint directly with a web browser?
Josiah, hitting the authenticator.php endpoint directly worked for me! It responded with an access token. However, using those same credentials via the API still fails.
If the credentials are being accepted via a browser request but not via calling code, it sounds as if the recent release involved a change that may have affected how some nuance of the request is being processed.
MG and OE - could you guys post some example code that reproduces the problem? I'm curious what language/library you're using to make the call.
I think I see what's happening. The authenticator endpoint expects a request with a content-type of application/x-www-form-urlencoded (simple key value pairs) in the POST data.
If you pass an array as the $data argument here
curl_setopt($ch, CURLOPT_POSTFIELDS,$data);
then PHP's cURL library will force the request into a multipart/form-data request (even if you explicitly set the Content-type header). Instead, generate a query string-style url encoded POST body (username=<username>&password=<password>&responseType=json) and it will use the correct content type. If can be useful to use
curl_setopt($ch, CURLOPT_VERBOSE, 1);
to tell the library to include useful information about how the request and response look when the call is made.
Indeed, it now works if I pass the arguments as a string!
The other endpoints, such as base_cost, successfully handle the parameters as key/value pairs. It seems that the authenticator endpoint handles it differently.
Excellent, I'm glad things are working for you guys. I'll be filing a bug to address the change in accepted content-types. Sorry for the inconvenience.
We haven't changed anything at this end in a long time and we've just started to receive this error yesterday. Any ideas?
Message edited by Off Exploring 4 months ago
Josiah Gore – 10 months ago
I've just checked to ensure I can successfully authenticate using my credentials. Are you able to login to the website using the email and password with which you are authenticating?
Off Exploring – 10 months ago
Hi Josiah,
Yes, I can log in to the website without any problems. I can confirm that the two sets of credentials are the same.
Josiah Gore – 10 months ago
I'm having trouble figuring out what's going on without being able to reproduce it. What happens if you
We did have a recent release that could possibly be related to the trouble you're having, but I don't know what could have caused a sudden inability to authenticate an existing account.
Moment Garden – 10 months ago
I'm seeing the same thing. I cannot authenticate with my username and password any longer, even though it worked fine before.
Moment Garden – 10 months ago
Also, Josiah, I tried resetting my password and creating a new account. Neither worked. Still seeing the response:
<luluAuthentication> <authenticated>false</authenticated> <message>You have entered an invalid email and/or password.</message> </luluAuthentication>
Off Exploring – 10 months ago
Hi Josiah,
I tried resetting the password on the account and updating the code - no change to the error
I also tried another account (one I'd created previously for a personal project) and I'm getting the same error.
Off Exploring – 10 months ago
(As an aside, the problem did seem to coincide with the "We're Renovating!" message and changes to the account screen.)
Josiah Gore – 10 months ago
You're right, there was a release last week that involved a fair amount of account-related code. I'm talking with that team and trying to figure out what could be going on. I'll update you guys as soon as I find something out.
Josiah Gore – 10 months ago
One possibility is that the call is going through a redirection. The URL that must be hit is
If you hit either of these URLs
the call will be redirected, and in the process (depending on your HTTP library) you'll likely be dropping the POST data and performing a GET on the new URL. This is not new behavior, however, so I'm not banking on that being the problem. I just wanted to make the suggestion in case it is.
Off Exploring – 10 months ago
Thanks for the suggestion - checked the code at this end and the call is directly to the https://www URL.
Best of luck with your investigation!
Josiah Gore – 10 months ago
Just to rule out the possibility that there is something wrong with the request, could you try hitting the authenticator.php endpoint directly with a web browser?
replacing the email and password as appropriate.
Moment Garden – 10 months ago
Josiah, hitting the authenticator.php endpoint directly worked for me! It responded with an access token. However, using those same credentials via the API still fails.
Josiah Gore – 10 months ago
If the credentials are being accepted via a browser request but not via calling code, it sounds as if the recent release involved a change that may have affected how some nuance of the request is being processed.
MG and OE - could you guys post some example code that reproduces the problem? I'm curious what language/library you're using to make the call.
Moment Garden – 10 months ago
Here's the PHP code I've used, with the credentials redacted.
Josiah Gore – 10 months ago
I think I see what's happening. The authenticator endpoint expects a request with a content-type of application/x-www-form-urlencoded (simple key value pairs) in the POST data.
If you pass an array as the $data argument here
then PHP's cURL library will force the request into a multipart/form-data request (even if you explicitly set the Content-type header). Instead, generate a query string-style url encoded POST body (username=<username>&password=<password>&responseType=json) and it will use the correct content type. If can be useful to use
to tell the library to include useful information about how the request and response look when the call is made.
Hope this helps!
Moment Garden – 10 months ago
Indeed, it now works if I pass the arguments as a string!
The other endpoints, such as base_cost, successfully handle the parameters as key/value pairs. It seems that the authenticator endpoint handles it differently.
Moment Garden – 10 months ago
Btw, Josiah, thanks for all of your prompt attention helping resolve this matter. It's greatly appreciated!
Off Exploring – 10 months ago
That's solved it for us too. Thanks for your help Josiah!
Josiah Gore – 10 months ago
Excellent, I'm glad things are working for you guys. I'll be filing a bug to address the change in accepted content-types. Sorry for the inconvenience.