I have some systems firing POSTs at Zapier webhooks. Occasionally the Zap that handles the POST is switched off. This is a situation I need to be aware of.
For the webhooks and raw webhook endpoints (made for my Webhook by Zapier Zaps), how can I determine which are failing to listen for incoming HTTP requests?
I've had a remote system assume that Zapier is going to receive the messages, instead they evaporate into nothingness.
Occasionally the Zap that handles the POST is switched off. This is a situation I need to be aware of.
There's a Zapier Manager app that does this! You can set the trigger to be "when zap X is turned off, which would notify you accordingly".
Re: Not knowing if your data is being received. That's interesting feedback and has been logged internally accordingly.
Related
The Twilio Console is confusing me. I can't seem to find a location where I can set the URL that my webhook is at for managing Opt Outs to my SMS campaigns.
I'm using a Messaging Service, and I'm on the Integration page settings of that service. Here's the screenshot:
I want to set it to “Drop the Message” (so I won’t be billed for incoming messages) – but now I want to understand how I can manage my opt-out requests. How/Where can I set which URL webhook they should go to?
Thanks for any help! :)
For Long Codes and Toll Free Numbers, the Opt-in/Opt-out is handled by Twilio.
Twilio support for opt-out keywords (SMS STOP filtering)
Or if you enabled Advanced Opt-out
Getting Started with Advanced Opt-Out for Messaging Services
I'm integrating Roku into our multi platform app with paid subscriptions model so webhooks/push notifications are crucial for business to know when subscription being renewed, cancelled etc. I came across Roku Push Notifications documentation which seems to have big security concerns or I'm missing the point:
Roku sends data down to our push notification url without any validation (e.g. like Stripe signature check does). So how do I know the data came from Roku and I can trust it?
They require to respond with our private API KEY(!) in the header... Does it mean that we can potentially expose it to anyone who found what the url is?
Not really a security concern but more of a business safety issue that they can stop sending push notifications without any notice if the endpoint fails consecutively which could lead to big problems again.
I would appreciate any advice on how to use Roku push notifications securely and if my concerns are valid at all.
I am currently developing a REST/JSON API using Play Framework 2.3. I am currently thinking about an efficient yet simple way to secure the API. By security, I mean that some actions need the end user to be authenticated to be accepted.
For the moment, I was relying on Play Framework session management (as a reminder, it stores all the session data in a signed cookie which is sent in every query - as such, it is stateless and even though the cookie can be read by the client, it cannot be updated).
The flow is quite simple:
The end-user logins thanks to the API client sending a login query
If accepted, a cookie is set in the reply
When sending next queries, the API client automatically adds the cookie, thus the end user is recognized by the API
My question is the following: do I really need to go further in term of security? I can't find a reason why this existing mechanism would not work correctly...
Thanks in advance!
PS: for the moment I am both developer and consumer of the API, and there's no plan for releasing it publicly.
PPS: the client I am developing is a simple webapp using AngularJS
You do not need. This is correct solution.
You can think to go to the tokens only in the terms of usability.
Of course I assume that you use https.
I'm working on a Windows Phone 7 application, and to go with it I will need a web service to send out live tile push notifications. I will save the clients URI channel in a database and every hour or so I will send out the correct live tile to all the subscribed clients. I will not be sending out any sensitive data to the clients, nor do the clients send any data to the service save for their channel URI, and I've made sure to protect the database against any sql-injections.
The exposed methods are for registering and unregistering a client, as well as sending the correct live tile to a client that requests it.
Given this information, does anyone have any recommendations on how I should secure the service, or is security even needed to begin with in this case?
Thanks!
EDIT:
Thanks for the answers! My peers decided to not use any security at all though, other than purging faulty requests from the database, since the scope of the application is quite limited and no sensitive data is being transmitted. Let's hope it won't bite us in our behinds later on, eh!
Unfortunately the best solution to this problem (at the moment) is to generate a hash in your app and use that to verify the data is really coming from your app. Obviously you'll need to obfuscate tyour code if doing this.
This is the best you can do without any authentication against the backend.
If you can, have the users register and authenticate with the backend and then tie this authentication token to the ANID of the device and do everything over SSL.
Unfortunately, currenlty, security of services and prevention of spoffed requests is quite tricky with WP7 without requiring a login to the backend.
Make sure you secure your channel to your backend service with SSL. This way the data you send to the server such as a the ChannelUri will be secure.
Building a hash into your application isnt security. People could get your XAP and decompile it to get the hash.
IMHO you are better to ensure your ChannelUri (unique to your app and not "stored" in your XAP anywhere) is secured when you send it.
On the backend just make sure you purge records that fail when you try and send it a tile notification. This will get rid of any records entered by non-phone parties.
Bottom line is that you need a login infrastructure with your backend to properly ensure only valid users are using your service.
i want to know that when we want to use push notification service.From where we send json payload, from our app or it may be generated on server? if it has to be sent from our app then how do we send json payload+device token to our own web server?
It can't be sent from your app. First off that would make no sense, if your app is running why would you have it send a push notification to itself.
Second, in order to communicate with the APNS servers you need a per app cert file to sign requests. You cannot distribute it without compromising the security of your applications push service.
Louis is absolutely right that you can't send messages from your phone, and his reasons are spot on. You'll definitely need to communicate to your own server, which will then send things on to Apple.
To send messages to your own server, look at ASIHTTPRequest - it's a fantastic package that makes it really easy to send HTTP requests.
On your server, you'll need to keep open a persistent connection to Apple's push service from your own servers and translate the JSON from the phone into a message to deliver to Apple.
There are at least two services out there that take care of the heavy lifting for you:
Urban Airship (full disclaimer, I work at Urban Airship)
iLime
You might want to look at one of these services to help you implement this. Again, I work at one, so take this with a huge grain of salt.
If you want to see some examples of how to use ASIHTTPRequest to send a device token to a server, you can look at our push sample application on bitbucket.