To me it looks like this tool (and cloudflair.py) can only ever find servers which are configured in a very specific way:
* The traffic between server and CDN is encrypted using a valid certificate
* The server's firewall is not properly configured
Apparently there are indeed servers with this configuration, but I just find it odd how someone would go through the trouble of setting up HTTPS (instead of terminating it at the CDN) and then not bother to block traffic from anywhere but the CDN.
Imagine someone with a fully configured HTTPS web server (without a front CDN), that adds Cloudflare in front of it when the load gets higher, and does not bother configuring their firewall.
Could be a shared hosting platform behind the CDN where the user doesn't have the ability to ip-acl but does have https. Common among low-end users and in the particular case of a "hidden" site, easily purchased cheap VPSes which are de facto anonymous.
Because I imagine someone who would expose their mongodb instance to the web would also just terminate HTTPS at the CDN, rendering curryfinger/cloudflare.py useless.
It seems the user created this because they thought that Postman required too many resources as an Electron app.
I'm not sure why they didn't just use a commandline tool (e.g. httpie [1]) that would work with any API, rather than just those with permissive CORS headers.
So Postman used to be a lightweight Chrome plugin. Then its developers turned it into an electron app with lots and lots and lots of features. They did this as a vehicle to begin offering paid features and enterprise plans.
To your second point, despite years of writing Curl some times its nice to have an interface and for some people that is their personal preference.
Yes, indeed. Sort of defeats the point of Postwoman being more performant..
Still, this seems safer than the various extensions that have been recommended in order to disable the SOP. I'd rather the user's data wasn't on the line.
I use Postman a fair bit, and looking through my history it's mostly playing with 3rd party APIs to see what format they return and how they respond to query params and such. So it works for that purpose, since those generally won't have CORS restrictions.
It probably won't work for testing of your own API endpoints for, say, a SPA, though, which is likely to have CORS. But for local testing where I control the backend, I mostly just rely on printing responses to the terminal anyway.
1. It doesn't accept my email address. Looks like the pattern is way too strict and doesn't allow any new TLDs.
2. The use-case I most often see Splitwise used for is trips abroad with friends. In this situation, expenses are often recorded while no internet connection is available and synced later. I'm not sure if IOU supports this, I haven't tried it.
1. Can you send an email to iou@iou.ch so I can check you address and fix the bug?
2. We will be building mobile apps as soon as possible with this functionality.
For reference, I didn't try any of the more obscure email address features, such as comments or quotation. My address simply has the form firstname@lastname.email
> just send an email with a confirmation link to see if it actually works.
Please don't enable anyone to just send emails to arbitrary email-addresses through you. That's how your email/domain will quickly get marked for SPAM.
At the very least, put in place a rate-limit per email-id (and source-ip too maybe). Otherwise i can simply keep entering email-ids of people to spam.
function c(i,j){return $("#color-"+i)[0].getContext('2d').getImageData(0,0,1,1).data[j]}
setInterval(function(){$("#color-"+(1+(c(1,0)+c(1,1)+c(1,2)<c(2,0)+c(2,1)+c(2,2)))).click()},1)
* The traffic between server and CDN is encrypted using a valid certificate
* The server's firewall is not properly configured
Apparently there are indeed servers with this configuration, but I just find it odd how someone would go through the trouble of setting up HTTPS (instead of terminating it at the CDN) and then not bother to block traffic from anywhere but the CDN.