it seems they have implemented some kind of DDOS prevention software and I can no longer access the ticker. does anyone know how to deal with this?
the service is working this morning so I guess it has nothing to do with the DDOS software but was probably a transient error. what gets me is that I could pull up the ticker from my browser but not from code, which is why I wrote. but it's working today
Related
I'm unabled to connect to my circuit sandbox for two days already. I tried to request new sandbox but there are error message. Do I missed some changes of how sandbox work now?
Apologies, but the only circuit sandbox datacenter is in Southflorida and it has been shut down due to hurricane Dorian. Should be up tomorrow.
We are looking at better announcing this, and moreover use multiple data centers so such downtime will not happen anymore.
I don't know if this is the right place to ask this question, but I have a problem with the Blockchain API V2, I tried too many times to request it, but never getting an answer nor my API!? I don't know why.
I searched the web looking for people whom having the same problem as I am, but find nothing. Also I didn't find a way to contact them asking about the delay in giving a simple API code!.
So if anyone has a better idea please let me know.
As an addition I am going to use it in a thirdparty software, where I am not able to add other Bitcoin payments instead of Blockchain one.
I don't know why exactly, but they have become extremely strict as to who they give API keys now. Previously it was very easy, and now they heavily investigate the intended usage. I wouldn't be surprised if the reason has to do with gambling sites and scams that were using their API.
As for recommendations you can run your own node on a VPS or use another 3rd party API. The only one that is as easy to use as blockchain.info, but actually gives out API keys is block.io. The catch is the free version is severely limited. There's also blocktrail, and blockcypher.
I have a php application using the BigCommerce PHP APi v 3.0, the application sends multiple API request to get some data on the store orders (it's a private application in BC), my problem is that of late more and more request are failing and my application is returning a 500 server error because of it. The behaviour is very odd because at times it works and at others it returns that error... Can anyone help me with this, has this happen to more ppl?
Thanks!
To answer my own question here, here's what i got as a response from BigCommerce support:
Thank you for contacting Bigcommerce and for your report.
The 500 errors you have been seeing in greater number this week last
week are expected as there have been several server performance
issues. A couple due to DDoS attacks, some relating to our object
storage system, and issues with our webhooks queue that specifically
affected the API proxy. We are sorry about these service interruptions
and know that our Technical Operations team and been working hard to
first correct then look to prevent the root issues. Assuming no new
issues crop up we should see a reduction in 500 errors back to more
expected, much less frequent levels.
We do appreciate your feedback on this and for bearing with us while
we work to get things back to normal operating levels. While 500
errors are something that can occur they should not be as frequent as
they have likely been seen this week.
Here's my issue. I have a site that provides some investing services, I pay for end of day data which is all I really need for my service but I feel its a bit odd when people check in during the day and it only displays yesterdays closing price. End of day is fine for my analytics but I want to display delayed quotes on my site.
According to the yahoo's YQL faq: If you use IP based authentication then you are limited to 1000 calls/day/IP, if my site grows I may exceed that but I was thinking of trying to push this request to the people browsing my site themselves since its extremely unlikely that the same IP will visit my site 1,000 times a day(my site itself has no use for this info). I would call a url from their browser, then parse the results so I can allow them to view it in the format of the sites template.
I'm new to web development so I'm wondering is it a common practice or a bad idea to have the users browser make the api call themselves?
It is not a bad idea at all:
You stretch up limitations this way;
Your server will respond faster (since it does not have to contact the api);
Your page will load faster because the initial response is smaller;
You can load the remaining data from the api in async manner while your UI is already responsive.
Generally speaking it is a great idea to talk with api's from the client. It's more dynamic, you spread traffic, more responsiveness etc...
The biggest downside I can think of is depending on the availability of other services. On the other hand your server(s) will be stressed less because of spreading the traffic.
Hope this helped a bit! Cheers!
I'm building a utility that will hopefully keep my wife in tune with how much money we have available.
I need a simple secure way of logging into my bank account and retrieving the balance.
Something like mechanize is the only method I can think of. I'm not even sure if that would work given the properly authenticated https that banks use.
Any ideas?
Write a perl script using LWP::UserAgent. It supports HTTPS connections. The only issue might be if the site requires javascript.
Web Client Programming with Perl has a few examples to get you started if you're not too familiar with perl.
If you really want to go there, get these extensions for Firefox: Live HTTP Headers, Firebug, FireCookie, and HttpFox. Also download cURL and a scripting language that can run cURL command-line tasks (or a scripting language like PHP or Perl that has access to cURL libraries directly).
I've started down this road for some idempotent GET tasks like getting PDFs of the S&P reports (of the stocks I track) from my online brokerage, and downloading the check images for my bank account. Both tasks are repetitive and slow ways of downloading data to my computer that the financial institutions don't provide any way of making it easier.
Here's why you shouldn't: (as a shortcut I'm going to call the archetypal large bank, brokerage, or other financial institution "BloatBank")
BloatBank is not likely to make public their API for accessing this kind of information. So it can change any time and all your hard work will be for naught. Whenever they change their mechanism, you'll have to adapt.
If BloatBank finds out you've been using automatic scripting to try to access your account information, they may ban you because you've violated their terms of service.
You might screw up, and the interaction between the hodgepodge of scripts on BloatBank's server, and your scripts that access your account, might cause a Bad Thing like closing your account. Testing this kind of script is tremendously difficult because you don't have any documentation about how their online service works, and you don't have a test account you can mess with.
(a variant of the above) You think you're safe because you're issuing GET requests. But BloatBank is just a crazy bank that doesn't know anything about REST, so there are some GET requests that can mess up your account.
If someone else does use your script to maliciously sniff your online password or mess with your account, any liability coverage from BloatBank may disappear because you've opened a security hole.
Why don't you teach your wife how to login to the bank herself? Or use Quicken (or Mint, etc) and teach her how to use the auto-download feature?
Have you checked out Watir? It is fantastic for automating web-browser actions. And since it's written in Ruby, you can take the results and store them in a DB (or email them to yourself) if needed.
If you are open to AIR, I'd say build an AIR app. I have worked with mechanize and I think it's cool. AIR gives you similar features with a richer GUI (see HTMLLoader and DOM manipulation of webpage).
If I were you, I'd simply pull the page and manipulate the DOM to suit my visual needs.
Please, if you find this easy to do for your bank please post your bank's name. If I have the same one I'll be closing my account.
More to your question. The process of loading a web page inside of your code rather than in a browser can be a black art, especially if their is any javascript involved. Your best bet would probably be embedding the IE Web Browser control in your app and then simulating key strokes and mouse clicks to arrive at your balance page. Then scrape the HTML for the balance.
I could try paying for Quicken and letting it do the balance downloading. Then I'd just need to find a way to get the number out of the software automatically.
This way I'm not violating any terms of service and I'm also reducing security risk since all "hacking" goes on locally.