Had an application using the /lists/subscribe endpoint of the MailChimp API (v1.3 v2.0) that was returning a "-100" error code for a particular address for a time (but it's cleared now.)
This isn't in their list of exceptions – anyone seen this before and know if it might indicate anything useful? Or if it's in that range, but not on the list of "known exceptions", does that just mean an unknown server error?
I'm using this PHP library to talk to the API.
(Of course if I can get an answer MailChimp themselves I'll update this.)
lists/subscribe is actually a v2.0 call. The v1.3 equivalent is listSubscribe. -100 is, IIRC, a validation error and it should come with more description about what specifically the problem was with your submission.
A common validation issue with subscribe calls is passing the email address as a string instead of a JSON Object. This, for example, will return an error:
{
"email": "some.person#somedomain.com"
...
}
Instead, you'd want:
{
"email": { "email": "some.person#somedomain.com" }
...
}
It's a common problem because it's kind of silly to require that format, but that is what's required nonetheless. There are a billion other ways to get validation errors, of course, but that's a good one to double-check.
Related
I've recently integrated enterprise reCaptcha to my application.
So, I've integrated both invisible and checkbox reCaptcha (works like fail-safe). In case user gets a low score in invisible captcha then they'll be shown the checkbox one.
The problem is that I'm always getting a score of 0 for invisible reCaptcha. And also reasons array is also empty in response, so I'm assuming that there's no validation error or something.
Is it something wrong that I'm doing or this is the expected behavior since there's not much traffic to site yet (it's still in localhost).
Any help is really appreciated.
Thanks :)
To me it happened 'cause I was not passing the parameters correctly.
Silly mistake :p
Here's a sample of it.
data : {
"event": {
"token": token,
"siteKey": siteKey,
"expectedAction": action
}
}
I am trying to filter SSPR results from AAD directoryAudits using:-
https://graph.microsoft.com/beta/auditLogs/directoryAudits?filter=category eq 'SSPR'
This works fine, however if I try to filter on say the result:
result eq success
"result": "success"
I get the error:-
"message": "The string 'Microsoft.AAD.Reporting.operationResult'success'' is not a valid enumeration type constant.",
So I have searched in the metadata and found some appropriate enums, and tried them, but nothing seems to work!
This seems such a simple thing, but I can't seem to work out a way past it.
I'm not sure if it is just this field, or enums in general.
Please help :)
According to the error message the string 'Microsoft.AAD.Reporting.operationResult'success'' is not a valid enumeration type constant, it means that $filter success is not supported.
Per List directoryAudits API, the following attributes are supported by $filter.
But based on my test and you mentioned that category also is supported.
If possible, you could filter the result on the client as workaround.
Currently in GraphQL JS implementation there is no standard way of returning a descriptive success message from mutation, such as "User created successfully", etc. My question has 2 parts:
My thinking is that it is beneficial to return a success message from the API. That way the messages can be uniform across different clients (e.g. web and mobile). Clients don't have to implement their custom messages for each API call. But I'm not sure what the best practice is. Are there any drawbacks of returning a descriptive success message from mutation calls (besides increased response size)?
If I decide to do it, is there a standard way in graphql-js to do this?
For example, is it possible to get back something like:
{
data: {
mutationName: {var1:"val1"}
},
messages: {
mutationName:"User created successfully"
}
}
Reasons not to do this
There is now a considerable amount of client code that depends on the shape of returned results being as they are. You would need to fork those if you were to implement your idea, at the cost of considerable effort, in order to benefit from your change.
Reason to stick with language spec as it is today
Meanwhile, what you want to achieve is (if I have understood you right) entirely achievable within the current spec.
Effective solution to stated problem
Why not do this (we'll make the mutation be user-creation):
schema {
mutation: Mutation
query: Query
}
type Mutation {
newUser(params: NewUserInput): NewUserResult
}
input NewUserInput {
# ...
}
type NewUserResult {
successMessage(languageCode: LanguageCode): String
newUser: User
}
# need to define Query, NewUserInput, User
This allows you to return a success message if that's what your system requires, without needing to change the spec of the GraphQL language.
If you really must...
(Source: graphql errors and status messages in graphql-js)
At least in express-graphql, there is a way to pass in extensions to it: https://github.com/graphql/express-graphql/blob/master/src/index.js#L89
I beat myself up for two days as I built a Ruby on Rails application that manages users in LDAP. While fine-tuning the inclusion and formatting of various attributes, I would frequently have ldap.add() fail with little feedback other than possibly an exception raised. I usually knew it was a data validation error, such as a missing required attribute or poorly formatted attribute values -- but I could not find anything on the server (Apache DS) or client end that would indicate which field failed, or why it was failing.
So...how do you see the reason why an LDAP add (or replace, delete, open...) failed?
Then I stumbled across ldap.get_operation_result, I had a real facepalm moment. I've intentionally recreated several of the issues I painfully solved through careful inspection with get_operation_result in my arsenal, and each time it described exactly what the problem was.
This function is useful in the case of rescuing an exception, or if add(), modify(), delete(), etc. simply returns false.
ldap.add(dn: dn, attributes: attributes)
Rails.logger.info("ldap.add: #{ldap.get_operation_result}")
The snippet above saved my sanity, not to mention hours of tedious hunt-and-peck testing.
For example, here is just one part of an error message it revealed that I did not provide the required sn attribute:
ERR_279 Required attributes [sn(2.5.4.4)] not found within entry uid=david,o=users,dc=example,dc=com"
It will also show messages related to bad server connection credentials, etc.
HTH
We have an internal database ID for each course we have. When using the batch function to create courses, the returned information doesn’t not give us any way to get this ID back so we cannot update our database and let it know that the course has been created.
Also updating the deletion response for the same reason would also be handy.
The response for a batch of deletes looks like:
--batch_123456
{}
--batch_123456
--batch_123456
{}
--batch_123456
--batch_123456
{}
--batch_123456
If they are all successful then it's not really a problem, but if something goes wrong then it's impossible to tell which ones were deleted and which ones were not deleted, because according to the API:
" The server may perform your calls in any order. Don't count on their being executed in the order in which you specified them."
A simple message that said "course #123 has been deleted" would be very helpful. That way I could program the callback code to update the database using the ID
For the course creation the response looks like:
--batch_123456
{
"id": "208571459",
"name": "***",
"section": "***",
"ownerId": "123456",
"creationTime": "2015-09-14T13:13:59.622Z",
"updateTime": "2015-09-14T13:14:02.820Z",
"enrollmentCode": "***",
"courseState": "PROVISIONED",
"alternateLink": "***"
}
--batch_123456
I only put in one response to save space. The ID is the new GoogleID of the course, the ID we actually send in which corresponds to the records in our DB does not get returned. So we have to use a combination of other data (ownerID + name) to get the record and update it, but this is not ideal and may not work fro everyone. Again adding in all of the information that get's sent into the response would be very helpful so we can use the callback properly.
I also want to add the more useful specific information should also be added to all error messages. In fact every batch response should have some sort of ID, that way the callback functions can be more useful.
As mentioned briefly in the documentation, you can pass an alias into Courses.id when creating a course to assign an alias to a course as you create it. The alias can include your internal identifier for the course and can be used in future requests.
Alternatively, each request in a batch can be assigned a unique Content-ID header, which will be returned in the response. Many client libraries provide built-in support for setting and getting these IDs.