I would like to see if anyone else already had this problem. I'm really struggling to find out an solution for that, so that's why I've decided to call for help.
So, i have this Ownbackup API endpoint:
Ownbackup API
Here's the link for the API documentation: https://cdn2.hubspot.net/hubfs/2571574/api%20document-1.html#tag/Enhanced-Sandbox-Seeding/paths/~1api~1v1~1sbs~1templates~1{template_id}~1seed/post
But for me it wasn't too helpful.
The point in here is that my organization has hundreds of validations rules. And I would like to know if there is any parameter that this API understands in order to disable ALL validation rules, without the need of passing the name of each one of the file names in the request body.
Keep in mind that the format for this request is multipart/form-data.
Thank you all!
So, I've reached out for Owbackup support and they told me that i can actually use "disable_validation_rules" set to true, so this way the All validation rules get disabled and the triggers not, also it does not require me to specify which validations rules should be disabled.
I'm letting this answer in here, in order someone else comes across this problem!
Cheers!
Related
I was building my API when this question came out:
I am making an API to set or get stuff, for the example i try to set but i have two field with error, what's the best way to answer the errors ?
Answer only one error ?
Answer all the errors ?
In my opinion, answer all the errors is the best solution but not for my boss .
What's the best for this kind of work ?
Definitely all validation errors should be pass back to client.
Moreover, you should specify code of errors, while error message can vary for different situation. Standard error codes can help you to create
tests for your api.
Also you should add versioning for your api from the beginning, because when you open your api for clients it should be stable. And incompatible changes can be done only in next version
of your api
Yii 1.1.16 brought getPatch($paramName, $defaultValue=null) and getIsPatchRequest() to life, but is there a way to loop through all PATCH parameters, without knowing their names? If a user wants to modify his tag line, but nothing else, how am I supposed to know that he wants to change user_tag_line?
Calling getPatch() gives
Missing argument 1 for CHttpRequest::getPatch().
I've solved it by using
CJSON::decode(file_get_contents('php://input'));
Is this safe, should this be used? Are there other ways of going about this?
When I call the rules https://storeId.mybigcommerce.com/api/v2/products/productId/rules for a product that has the rules applied from the option set I get a 204 No Content error.
Is this something temporary? Does anybody have the same issue?
Actual links:
https://store-9j2twtgd.mybigcommerce.com/api/v2/products/54/rules
https://store-9j2twtgd.mybigcommerce.com/api/v2/products/54
i faced the same issues with a couple other API requests. What i realized is that due to content negotiation, you have to state the format in which you cant your response.
For example if i want a specific product, i have to do
https://storeId.mybigcommerce.com/api/v2/products/productId.json
In this same regard, i would suggest that you do same with the rules resource. so try out
https://storeId.mybigcommerce.com/api/v2/products/productId/rules.json
Hope this works.
I need to require multiple authentication types in my app; in particular: some parts of the app require authentication to dropbox, and some parts require email-based authentication such as browserID.
How can I handle this?
Can I attach authentication to a subsite? Since the YesodAuth class takes the master foundation data type as its argument in all the examples, it's not obvious how I can do that.
If not, is there some other way?
Apologies if my answer is a tad vague (it's been a few months since I've used Yesod, and the dev cycle is quite rapid), but if I remember correctly you can specify multiple varieties of authentication within the YesodAuth class (browserID, google etc), in which case the user would be provided with the option as to which to use at each authentication request. Something like:
authPlugins _ =
[ authBrowserId
, authGoogleEmail
]
etc.
Whether or not you can explicitly set one auth type for each circumstance I do not know I'm afraid, and whether or not this solves your problem I'm unsure.
To deal with recent growth our application has been split across two sets of separate infrastructure. Approximately half of our customers are on set 1 and the other half are on set 2.
Both sets have different urls (api1.ourdomain.com and api2.ourdomain.com).
Problem is clients accidentally putt the wrong url and then wonder why they get error messages.
Other then user education any other strategies for dealing with this mess?
Is it possible to redirect requests to the correct endpoint?
Thanks.
I don't think your question is detailed enough to provide meaningful feedback. There are obviously several factors that could easily contribute to a recommendation.
Does your application make use of user profiles (or a similar construct)? If so you might consider associating a primary URI for each user in their profile and include logic in your application to interrogate the profile for each request and redirect if a user goes to the wrong URI.
Is this an authorization issue? If so you might consider including some basic authorization routing that provides a custom 403 page with the proper URL.
If you could provide additional detail I think we could be more helpful.