Changing A DNS record using ModifyDNS() method, reports success but DNSMANAGER disagree - godaddy-api

I'm working in a solution for my company. I'm using the Godaddy API. The methods Describe(), CheckAvailability(), and OrderDomains() are working perfectly but I'm trying to change the A DNS record with ModifyDNS() method and their response is:
[ModifyDNSResult] =>
<response>
<result code="1000"/>
<resdata>ModifyDNS OK</resdata>
</response>
As you can see the result is success but when I check in my DNSMANAGER the IP is the same.
I have read:
https://stackoverflow.com/questions/13101906/changing-a-record-using-godaddy-api, https://api.wildwestdomains.com/wswwdapi/wapi.asmx, https://img1.wsimg.com/Rex/docs/WWDAPI_WebServicev2_5.pdf.
I made a request to Godaddy API support, and after around 20 days they said: "The issue has been addressed and should be resolved at this time" and I still getting the same issue. Anyone know how can I resolve this issue?

Definitely I moved to http://www.domainbox.com/. Godaddy never answered my requirements with his API.

Related

Odoo - Long process leads to XmlHttpRequestError BAD REQUEST error

In odoo while I am doing any long process such as getting data from
amazon and process those data in odoo and after 5-10 min I am getting
this error don't know the reason why this happen.
XmlHttpRequestError BAD REQUEST
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>400 Bad Request</title>
<h1>Bad Request</h1>
Invalid JSON data: ''
The process seems running in background in server but I am getting this error every time. This leads users into the wrong direction.
I am wondering why I am always getting this error? Is that a normal behavior ?
Even data processing will be done properly even after getting this
error, so I am not getting the meaning why this error pop out only in
long process.
Is there timeout issue happen with web server ?
Where I need to look out for that ?
UPDATE
I have did this process from different system and it seems everything
working fine over there.
So what my guess is "It is something related to browser end only"
May be browser is not able to manage such idle requests (may be any
request time out settings needs to be updated)
Solution:
It wasn’t clear at first but the tracing telling me exactly what the problem is “cookie”.
The problem was due to a cookie that has become corrupted. Not sure
how it got that way but it seems that the last time it was generated
something went wrong. The easy solution is to delete all your
cookies of that particular domain or should do this from private
window (incognito mode).

How do you get IBM MobileFirst Platform ChallengeHandler to handle very large responses correctly?

When working with a large-sized data response from an HTTP Adapter, the size of the response appears to cause our challenge handler to fire a handleChallenge() method.
My question is, why would the size of the response cause the mobilefirst security challenge handler to fire, when the session is still valid?
More Details:
Our application uses an ISAM security appliance with Header based authentication. When an HTTP adapter call we make comes back with a content-length greater than 20,377, the adapter call triggers the handleChallenge() method of our challenge handler. When inspecting the response, we have seen that the responseJSON is actually populated with our required data, so really the handleChallenge should never have fired.
When we ping the adapter directly through the browser with the same parameters, it works fine. We've been able to isolate that this problem is occurring in the worklight.js / mobilefirst realm.
Does anyone have any idea if, or why, the Challenge Handler in worklight.js would not function as expected with a very large response size?
The bottom line is that it should. There is no reason for it not to.
If you have not been able to resolve this otherwise, my suggestion is to open an IBM PMR (support ticket) to have the development team investigate the issue.
We ended up ( sort of ) diagnosing it. At a certain payload size, the "/*secure {" fell off the response ( of which we're still not certain why. Our loginChallengeHandler function was based off of some example we found in some IBM documentation, and would improperly mark the response as a login form if the /*secure wasn't present. Once we tightened up the challenge handler, it worked.

Use AWS S3 success_action_redirect policy with XHR

I'm using signed POST to upload file directly to amazon S3. I had some trouble with the signature of the policy using PHP but finally fixed it and here is the sample of code.
This xhr request is send in javascript and I'm waiting for an answer from amazon. At first I was using success_action_status setting it to 201 to get the XML response.
What I'd like to do is using the success_action_redirect to call a script on my server to create a record in the database.
The reason why is that I could create the record in the database and if anything wrong happen at this stage I can return an error message directly at this point. Also it saves me another ajax request to my server.
So I've tried to set this up specifying the success_action_redirect to http:\\localhost\callback.php where I have a script that is waiting for some parameters.
But it looks like this script is never called and the response of the xhr.send() is empty.
I think it's a cross-browser issue and I'm wondering if it would be possible to use jsonp somehow to pass-by this?
Any ideas?
UPDATE
Apparently xhr is following redirect natively so it should work but when I specified the success_action_redirect it returns error Server responded with 0 code.
At first I thought it was because the redirect URL was on my local server so I've changed it to an accessible server but no chance.
Anyone knows why it's returning this error message?
I also run into this problem. It seems like nobody has a solution to this like this
maybe the best workaround i have found is something like this.
It seems thet the only workaround includes a second xhr-request to execute the callback manually. therefore the
success_action_status
should be used. Witht his you will get a 201 response if the upload was successful and you can start a second request for the actual callback. For me it looks like the only possible solution at the moment.
Any other solutions?

WCF Fault - missing detail element

We have a custom exception handling behaviour (implementing IErrorHandler) in our solution which essentially uses Automapper to convert exceptions to faults.
This has been working well since day 1. However we have just noticed while browsing ServiceTraceViewer (looking at server logs - not client) on our shared development server that any faults returned from our services omit the detail element.
Running exactly the same code and configuration on my development machine, the detail element is correctly populated. As I say configuration files (behaviours, bindings) are identical on both machines. Both configurations do specify includeExceptiondetailsInFaults = true.
I've also added a bunch of log statements that seem to indicate that the same code path is followed on both machines with the same values for various things like fault code, fault reason etc.
My dev machine is 2008R2 standard (64bit). The server in question is also 2008R2 Standard (64 bit).
I can post extracts of the code if required, but in the first instance is there anything environmental that could allow for what we're seeing?
Extract from problem file:
<s:Body u:Id="_1">
<s:Fault>
<s:Code>
<s:Value>s:Sender</s:Value>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-NZ">An error occured during the request to the ...</s:Text>
</s:Reason>
</s:Fault>
</s:Body>
Not 100% sure about etiquette here. This is an answer I guess to my specific brand of stupidity. Maybe somebody else will be as stupid, then the answer applies to them...
I was sure I had compared everything (I stated exactly the same code / configuration). But the behaviour configuration file I just gave a quick visual. After another developer approached me I realised that the local files were NOT the same as the server files. Doh!
In fact the server files had one extra line added by a post build step - triggering another custom behaviour which implemented IErrorHandler in addition to the IErrorHandler behaviour we already use for logging etc.
I guess I'm going to open another question now which seeks an answer to the approach on having multiple behaviours implementing the same interface and not polluting eachothers functionality (like returning Faults).

eBay XML API returns 'Invalid job context type' error

I am developing eBay manager that is almost completed. Everything is running fine, like posting of data, getting order details from eBay.
Now I need to update the status of Shipping Tracking numbers, Carrier on eBay. Here I am getting error and I can't figured out what is the problem. Any help in this regards will be highly appreciated.
Help Reference: http://developer.ebay.com/DevZone/XML/docs/Reference/eBay/CompleteSale.html
Error response:
<?xml version="1.0" encoding="UTF-8"?>
<GetSellerTransactionsResponse
xmlns="urn:ebay:apis:eBLBaseComponents"><Timestamp>2010-01-13T12:50:29.644Z<Ack>Failure<Errors><ShortMessage>Invalid
job context type<LongMessage>The job context object
is not supported by Action Service
Framework.<ErrorCode>21843<SeverityCode>Error<ErrorParameters
ParamID="0"><Value>GetSellerTransactions<ErrorParameters
ParamID="1"><Value>CompleteSaleRequestTypeRequestError<Version>643<Build>E643_CORE_BUNDLED_10284414_R1</GetSellerTransactionsResponse>
I got this error when accidentally having the wrong X-EBAY-API-CALL-NAME value for the call I was making.
For example, in my header I put GetSellerEvents, but my request body was using GetSellerList.
Hope that helps!
Joe
Just had a similar issue. I had non-matching values in the headers and the XML; I had AddItem in the header, but VerifyAddItemRequest in the XML. (A copy and paste issue). The XML part needs to be AddItemRequest in this case.
After fixing this, I made my first-ever successful item listing in the sandbox.