to accurately determine the current machine's external IP address, as the one reported by the operating system may be inaccurate (doesn't take into account NAT, proxies, firewalls etc)
If you're talking about email, Webscript can be made to talk to an SMTP server, but whoever writes the script could presumably have talked directly to that SMTP server instead, and that would have been more efficient. So why would Webscript be used for spamming?
For anonymity, I guess. If the spammers write scripts to send emails from your servers, the authorities can’t track down the spammer’s servers and shut them down. And the spammers would be able to just keep creating anonymous accounts and using your site to spam after each spam-script is individually shut down.
I don't think this is a real issue. For the scenario you're imagining, there would have to be an SMTP relay somewhere that met the following requirements:
1. It doesn't require authentication. (If it required authentication, then there would be no way to gain anonymity.) I think this is extremely rare these days.
2. Other SMTP servers are willing to receive mail from it. This seems unlikely, since such a server is almost certainly going to be used to send a lot of spam.
3. This open relay keeps track of the sender in some weak way (since there's no authentication), like perhaps IP address. (If this weren't the case, there would be no reason to use a third-party service to hide your identity.)
If you could find some SMTP server that met all these requirements, then you would have motivation as a spammer to use a third-party service to hide your IP address. But a VPN would be a better way to do that then using something like Webscript. Webscript will be comparatively slow, we're likely to shut down a spammer because their traffic will be heavier than what we expect/allow, and we don't have a lot of IP addresses, so we would certainly just get blocked at some point just as the spammer would have if they hadn't been using us.
I'd say it's even less capable. Shared hosting providers typically allow the use of Perl, Python, PHP, Tcl, Lua and sometimes other languages for CGI scripts. From what I can tell, this service limits you to Lua only.
Definitely! Just as a shared hoster is less capable than running your own VM and a cash register is less capable than a laptop. That doesn't mean those things aren't useful. :-)
I'd say that most of the time, people are more productive with more specialized tools if the tool happens to specialize in what they're trying to do.
Looks like a cool project, but I'm not sure how it would be useful. In the demo video and examples they talk about how it can handle credit card payments via Stripe... why would I want to another party—that contributes virtually nothing—to a credit card transaction?
I also wonder how they deal with abuse. If not restricted, this could easily be used in a DoS attack for example.
Generally, I think our customers fall into two large buckets:
1. Experienced developers who want something lighter-weight than, e.g., Heroku.
2. Inexperienced developers (perhaps even first-time developers) who are trying to do something simple (e.g. send themselves a text message when a webhook fires).
To take your Stripe example, I imagine based on your question that you're thinking about the case where you have a server-side app already, in which case handling Stripe is very little extra work. If you are instead, for example, selling a digital good via a static website, Webscript would be a lot easier than building a full web app. You could have the job done via Webscript by the time you created a new app and set up your git repo for Heroku.
As to the DoS attack angle, do you have an example of how you see Webscript being used for something like that? If you mean flooding some target with HTTP requests, it seems like it would be more efficient for an attacker to send the requests themselves rather than try to funnel them through Webscript.
I love webscript.io, and am part of the second group – I want to accomplish some sort of webhook-based workflow, with minimal effort or scaffolding. I've used it a few times for hackdays, and it's great how simple + fast it makes it to go from an idea to a rough implementation.
Hi! Nice product, I'd like to upgrade. But I don't want to use Stripe. Any plans to use something else - btc/paypal - as a payment method in the future?
I really like the idea - put the LuaVM to great use handling this and make things really simple with a hosted namespace. I'll be using my free account in the next few days ..
Not supported all over Europe, so its a pretty nasty dissection of my market. Not everyone uses credit cards these days, and fewer and fewer folks are as willing to just hand over such details as they used to .. Paypal has better European-market support and just plain works for a lot of my customers, which is why I asked.
I'm in Europe, where Stripe support is quite spotty, and also I don't want to expose my credit card/customer credit cards to yet another 3rd party. Paypal is the #1 payment method chosen by my customers, so that is important to me.
For you Americans - Stripe may seem 'global' but in fact its far from it. At the moment only 5 western nations are officially supported, with 12 more in beta - well thats not going to be very good for those of us with a bigger market share than the 17 countries where Stripe is currently able to operate. Its a start - but its too much of a limit.
>At the moment only 5 western nations are officially supported, with 12 more in beta
Isn't the "support" just for entities accepting payments with Stripe, rather than the customers who are actually paying? I ask this because I accept payments with Stripe, and have seen cards processed successfully from many countries, even non-Western countries that Stripe doesn't offer merchant support in.
I understand that shopping online in Europe is a bit more complex with the EMV/Visa Electron system that is popular in the region, so I get where PayPal would fit in here since it can be linked to a checking account. Just wondering what specifically you mean by Stripe not "supporting" certain regions.
The problem is the 'accepting payments' that you refer to is 'paying by credit card' - where this is usually universally possible - but if you don't have a credit card and want instead to pay with cash by linking your bank account, Stripe doesn't have the mechanism in place to do that yet, in all banking markets in Europe.
Since America is run by its credit cards, I can understand why this is difficult to understand, but a majority of folks in Europe simply don't use credit cards, preferring always to pay cold hard cash. It's just different. And existing payment infrastructures - such as paypal and so on - already solved this problem as well as they can, decades ago, so to be honest its sort of lame to have to be explaining this already about Stripe. Stripe currently has a lot of hype, and as a service it is good for us merchants where our markets are limited to those regions also bound by Stripes' investment into its infrastructure, but outside of that: Stripe is quite a bit mediocre in this market.
Europe is a big place, which is why its disappointing that Stripe doesn't cover a majority of the EU region .. yet .. but you are mistaken in thinking that credit card use is as common as it in the US - in fact, its not the case. Direct-deposit is far more common, even still today - Europeans' don't have such a dependency on personal credit as the American market demonstrates, alas ..
$5/month for unlimited everything seems ... problematic. Let's say I implement a lightweight service for backing up photo libraries (we're not even talking deliberate abuse here).
When someone starts hitting us with a lot of concurrent requests or storing a lot of data, we do sometimes have to ask people to change what they're doing.
Is there a particular reason you don't think heavy users would be willing to pay heavy enough money to make themselves worth it? In my experience people who use your thing 2x heavier than normal are willing to pay more than 4x to keep using it because it's important to them in a serious way.
Usually I see startups handling this by having a "call us" pricing mode, which I have always assumed meant "We want to establish a proper business partnership with you that goes beyond being just a user"
One big issue is that we're just not a good product fit for something heavy, so I would expect most people who want more than what we'll give them for $4.95/month to eventually discover that Webscript is the wrong service for them. (For example, technology-wise, they should be using something that doesn't spin up a new Lua VM on every web request.)
We could certainly adapt Webscript to be a better product for bigger workloads, but that would be a lot of work on our side, and that product might end up just being "Heroku but with Lua," which is probably a bad product. :-)
I also doubt that your experience applies here in terms of those heavy users wanting 2x the use for 4x the price. At 4x the price, Webscript would cost close to $20 per month, and we would start to compete price-wise with shared web hosting or VM hosting solutions. I'm not sure there are really users who want something like Webscript for that price.
"Choose a URL" made me think this was for scripting a web client to interact with another site. Like you'd enter "www.imdb.com" as the URL and write a script to find the latest movies opening.
37 comments
[ 3.0 ms ] story [ 93.5 ms ] threadhttp://jsonip.webscript.io/
[1] https://twitter.com/smarx
What do you mean by spammers?
If you're talking about email, Webscript can be made to talk to an SMTP server, but whoever writes the script could presumably have talked directly to that SMTP server instead, and that would have been more efficient. So why would Webscript be used for spamming?
1. It doesn't require authentication. (If it required authentication, then there would be no way to gain anonymity.) I think this is extremely rare these days.
2. Other SMTP servers are willing to receive mail from it. This seems unlikely, since such a server is almost certainly going to be used to send a lot of spam.
3. This open relay keeps track of the sender in some weak way (since there's no authentication), like perhaps IP address. (If this weren't the case, there would be no reason to use a third-party service to hide your identity.)
If you could find some SMTP server that met all these requirements, then you would have motivation as a spammer to use a third-party service to hide your IP address. But a VPN would be a better way to do that then using something like Webscript. Webscript will be comparatively slow, we're likely to shut down a spammer because their traffic will be heavier than what we expect/allow, and we don't have a lot of IP addresses, so we would certainly just get blocked at some point just as the spammer would have if they hadn't been using us.
I'd say that most of the time, people are more productive with more specialized tools if the tool happens to specialize in what they're trying to do.
I also wonder how they deal with abuse. If not restricted, this could easily be used in a DoS attack for example.
Generally, I think our customers fall into two large buckets:
1. Experienced developers who want something lighter-weight than, e.g., Heroku.
2. Inexperienced developers (perhaps even first-time developers) who are trying to do something simple (e.g. send themselves a text message when a webhook fires).
To take your Stripe example, I imagine based on your question that you're thinking about the case where you have a server-side app already, in which case handling Stripe is very little extra work. If you are instead, for example, selling a digital good via a static website, Webscript would be a lot easier than building a full web app. You could have the job done via Webscript by the time you created a new app and set up your git repo for Heroku.
As to the DoS attack angle, do you have an example of how you see Webscript being used for something like that? If you mean flooding some target with HTTP requests, it seems like it would be more efficient for an attacker to send the requests themselves rather than try to funnel them through Webscript.
It's nice to see Webscript back on HN. You may enjoy reading the discussion from a couple years back when we first launched: https://news.ycombinator.com/item?id=4718686.
I really like the idea - put the LuaVM to great use handling this and make things really simple with a hosted namespace. I'll be using my free account in the next few days ..
Is there a reason you don't want to use Stripe?
For you Americans - Stripe may seem 'global' but in fact its far from it. At the moment only 5 western nations are officially supported, with 12 more in beta - well thats not going to be very good for those of us with a bigger market share than the 17 countries where Stripe is currently able to operate. Its a start - but its too much of a limit.
Isn't the "support" just for entities accepting payments with Stripe, rather than the customers who are actually paying? I ask this because I accept payments with Stripe, and have seen cards processed successfully from many countries, even non-Western countries that Stripe doesn't offer merchant support in.
I understand that shopping online in Europe is a bit more complex with the EMV/Visa Electron system that is popular in the region, so I get where PayPal would fit in here since it can be linked to a checking account. Just wondering what specifically you mean by Stripe not "supporting" certain regions.
Since America is run by its credit cards, I can understand why this is difficult to understand, but a majority of folks in Europe simply don't use credit cards, preferring always to pay cold hard cash. It's just different. And existing payment infrastructures - such as paypal and so on - already solved this problem as well as they can, decades ago, so to be honest its sort of lame to have to be explaining this already about Stripe. Stripe currently has a lot of hype, and as a service it is good for us merchants where our markets are limited to those regions also bound by Stripes' investment into its infrastructure, but outside of that: Stripe is quite a bit mediocre in this market.
Ehm? Europe's a very big place, and in many European countries credit cards are just as common and as commonly used as in the US.
You don't give them a chance to pay more for the service?
(I guess that's a sort of trivial answer? Feel free to ask follow-up questions if you're genuinely curious about it.)
Usually I see startups handling this by having a "call us" pricing mode, which I have always assumed meant "We want to establish a proper business partnership with you that goes beyond being just a user"
We could certainly adapt Webscript to be a better product for bigger workloads, but that would be a lot of work on our side, and that product might end up just being "Heroku but with Lua," which is probably a bad product. :-)
I also doubt that your experience applies here in terms of those heavy users wanting 2x the use for 4x the price. At 4x the price, Webscript would cost close to $20 per month, and we would start to compete price-wise with shared web hosting or VM hosting solutions. I'm not sure there are really users who want something like Webscript for that price.