We have an application that depends on ORN.
We want to have a health check endpoint for that application to know if it works fine and all its dependencies work fine.
In order to check if ORN is working, currently we are using:
https://support.something.com/cgi-bin/something.cfg/services/soap?wsdl
as health check endpoint for ORN. It works fine, but it's too big (1800 lines):
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright # 2009, 2017, Oracle and/or its affiliates. All rights reserved.
http://www.oracle.com
-->
<wsdl:definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
...
</wsdl:service>
</wsdl:definitions>
Is there another health check endpoint for ORN?
Ideally, I'd like something to have something like this:
https://support.something.com/cgi-bin/something.cfg/check
that returns just
OK
Are you actually trying to test the availability of the SOAP API, all APIs, the Customer Portal, or something else. Depending on your test, the answer will be different. APIs might be up while CP is down, or any potential combination of the distributed components of the platform.
For the SOAP API test that you have, rather than checking for WSDL availability, you could try one of the SOAP operations that returns fewer lines; a ROQL query would probably be a good choice.
The REST API would probably be the root "connect" path, which doesn't require authentication. https://my.osvc.site.com/services/rest/latest.
For Customer Portal, you could just hit the index/home page, which would tell you that CP is up.
Chat could use a REST/SOAP approach as mentioned above.
Email probably cannot be checked in any useful way in this manner.
Of course, you could implement a CP controller or custom script that acts as an API endpoint, but that is not a best practice and will probably not be a good longterm solution, even though such practices are commonplace in the SI space currently.
Related
I'm trying to send different message cards to multiple teams channels.
I have already created a webhook (telekom/webhook) for this which gives me the right variables via json.
There are four department receiver channels (telekom/rest-api-component) which are also configured to send pre-formatted teams message cards with the variables they have submitted.
Currently this happens to all channels at the same time. In between I would need an "action" in which I can decide which of the channels is served based on the input values. Unfortunately I don't find anything suitable due to the variety of the apis. Do you know how I could realize this ? So something like if value department = Backoffice then (Teams "Account Management") action.
In order to be able to talk with the different applications from Office 365 I wanted to use the Microsoft Graph api which is now available for some time. I couldn't find them in Flowground. Are you planning to include this module ?
For the implementation with Office365 flows this would be absolutely necessary for me.
I want to come back to this question: The CBR is a good choice for executing decisions indeed. But is is this the best solution in every situation? I do not think so.
Assume the following task:
Depending on an input parameter test you want to fire a request to different web services (WS1:google.de and WS2:bing.de)
Solution 1: You realize the requests with dedicated connectors for WS1 and WS2.
In this case you need the CBR in front of WS1 connector and WS2 connector to decide, what connector has to been used next.
Solution 2: You are able to realize both requests with REST-API connector. In this case you can use a JSONATA expression as URL mapping, e.g.
(test="google") ? "http://google.de" : http://bing.de
By using JSONATA expressions every connector has (limited) capability for executing decisions.
Solution 2 has a big advantage when you are using realtime flows. In this case you are able to reduce the number of connectors they are needed for running the flow and (very important from a cost perspective ) the number of permanently claimed token by this flow.
For reducing the complexity of JSONATA expressions (e.g. when you add further search engines) and for separation of individual configuration items you can use the configuration connector (we can discuss this in a separate thread if needed).
Solution 1 is the choice without alternative when you have to decide between different structures/connectors they need to be executed within a flow.
Please try the Content-Based-Router: https://doc.flowground.net/guides/content-based-router.html, it is available on the Connector Catalog.
I've searched for this a bit on Stack, but I cannot find a definitive answer for https, only for solutions that somehow include http or unencrypted parameters which are not present in my situation.
I have developed an iOS application that communicates with MySQL via Apache HTTPS POSTS and php.
Now, the server runs with a valid certificate, is only open for traffic on port 443 and all posts are done to https://thedomain.net/obscurefolder/obscurefile.php
If someone knew the correct parameters to post, anyone from anywhere in the world could mess up the database completely, so the question is: Is this method secure? Let it be known nobody has access to the source code and none of the iPads that run this software are jailbreaked or otherwise compromised.
Edit in response to answers:
There are several php files which alone only support one specific operation and depend on very strict input formatting and correct license key (retreived by SQL on every query). They do not respond to input at all unless it's 100% correct and has a proper license (e.g. password) included. There is no actual website, only php files that respond to POSTs, given the correct input, as mentioned above. The webserver has been scanned by a third party security company and contains no known vulnerabilities.
Encryption is necessary but not sufficient for security. There are many other considerations beyond encrypting the connection. With server-side certificates, you can confirm the identity of the server, but you can't (as you are discovering) confirm the identity of the clients (at least not without client-side certficates which are very difficult to protect by virtue of them being on the client).
It sounds like you need to take additional measures to prevent abuse such as:
Only supporting a sane, limited, well-defined set of operations on the database (not passing arbitrary SQL input to your database but instead having a clear, small list of URL handlers that perform specific, reasonable operations on the database).
Validating that the inputs to your handler are reasonable and within allowable parameters.
Authenticating client applications to the best you are able (e.g. with client IDs or other tokens) to restrict the capabilities on a per-client basis and detect anomalous usage patterns for a given client.
Authenticating users to ensure that only authorized users can make the appropriate modifications.
You should also probably get a security expert to review your code and/or hire someone to perform penetration testing on your website to see what vulnerabilities they can uncover.
Sending POST requests is not a secure way of communicating with a server. Inspite of no access to code or valid devices, it still leaves an open way to easily access database and manipulating with it once the link is discovered.
I would not suggest using POST. You can try / use other communication ways if you want to send / fetch data from the server. Encrypting the parameters can also be helpful here though it would increase the code a bit due to encryption-decryption logic.
Its good that your app goes through HTTPS. Make sure the app checks for the certificates during its communication phase.
You can also make use of tokens(Not device tokens) during transactions. This might be a bit complex, but offers more safety.
The solutions and ways here for this are broad. Every possible solution cannot be covered. You might want to try out a few yourself to get an idea. Though I Suggest going for some encryption-decryption on a basic level.
Hope this helps.
Hi i have googled all day long but i can't find an answer.
I have to write a web app which talks to asterisk.
It should be able to do ClicktoCall operations.
Can you guys recommend something ?
I came across a few projects but I'm still not sure.
I just want to connect to Asterisk and do calls from the web app.
thanks
If you're a Ruby programmer the best way for you to hook into Asterisk is adhearsion. It wraps up Asterisk's AGI and Manager (MAPI) APIs for you.
Also hAve a look at SIP, asterisk, adhearson and VoIP and in particular Adam Kalsey's answer. He works for Tropo which sponsor the adhearsion project.
First you need to know, that the protocol Asterisk uses is SIP, you can learn more at the Wikipedia.
Since you want to use an rails application, you may want to use ruby as well, so there's a ruby implementation named OverSip, you can check their API and see if it fits your requirements.
If you are aiming at web calls, you'll need an WebRTC, Flash or Java applet. For WebRTC you can check sipML5 for an opensource solution.
You can also opt for an interface, that will start a call from one number to another, using your phone. When the first call is picked up the server starts ringing in the destination.
Also you could make use of cloud communications providers like twilio, tropo, etc.
Try this Google search:
rails asterisk manager interface
I saw some interesting things right off. I am not trying to be one if those Use Google type people, just didn't want to paste all the links in that I found from this Google search.
Check it out, hope it helps.
There are several ways to do this but the three easiest ones are
1. Generate a call file on the Asterisk server
These files should be written to the dir
/var/spool/asterisk/outgoing
Asterisk will then pickup the file, process and delete it.
It's pretty aggressive when doing this so it's recommended to write the file into a temporary directory and then move it to the spool dir for processing.
An tutorial of the file format is here:
https://www.voip-info.org/asterisk-auto-dial-out/
(I personally feel this is a bit "hacky", and prefer doing it with an API call)
2. Generate the call by the AMI API interface.
Use the Originate function of the AMI API to generate the call. It's pretty easy to set this up just configure the manager.conf file whitch sets up a HTTP server on port 5038 from witch you can call the API.
https://www.voip-info.org/asterisk-config-managerconf/
3. Set up the call using the ARI API
First you need to setup ari.conf, this is enough for now:
[general]
enabled = yes
pretty=yes
allowed_origins=http://ari.asterisk.org
[my_username]
type = user
read_only = no
password = my_password
password_format = plain
This is a little bit more complicated to set up, but it really isn't that hard if you just get past the technical geek-speak. Just set up two channels, setup a mixing bridge and add both channels to the bridge.
To set up a click2call you dont even need to do that...
This is the call we use (ruby):
where
#{sip_id} is your registered SIP username
#{number} is the extension that is sent to the dialplan
#{USERNAME}
#{PASSWORD} is from ari.conf
HTTParty.post("http://sipserver.com/ari/channels?endpoint=SIP/#{sip_id}&extension=#{number}&context=outgoing&priority=1&timeout=30&api_key=#{USERNAME}:#{PASSWORD}")
(Note that you need to send the variabels for the variable parameter as a separate JSON for the originate command if you need to send them)
A really useful tool to understand how this works is the swagger at
http://ari.asterisk.org. We already allowed this origin in ari.conf so it should be ready to go. Remember to open your ports in firewalls etc.
Setup your Server IP and port and the API_KEY is in this format: my_username:my_password
I'm working on a Firefox add-on. At one point in the add-on, it needs to contact my server, give it a URL, then the server will process the URL (it's not a quick or easy process) and send back a link to the resulting file (on Amazon S3). However, since Firefox add-ons are mostly open-source by nature, how can I protect that one call to the server from being discovered by malicious people and then abused? (I only want users of my add-on to be able to make that call to the server...)
I was thinking about using some sort of key or something, but since Firefox add-ons are all open-source that wouldn't really work. I also thought about writing a binary component, but I have almost no experience in C++ (but maybe for something simple like this I could learn) - but then how could I protect calls to the binary component? Also, how could I protect from network sniffers and such? Would it be possible to somehow include encryption of some sort in that binary component so network sniffers cannot detect what is being sent to the server? (I found this question: Client-Server security and authentication but it was a bit over my head.)
When you distribute an extension you are basically giving people the car keys, so it's hard to stop them from taking the car for a joyride. The most secure solution is the one you suggested: use a binary component and authenticate the connection with username/password or PKI certificates. If you use HTTPS then the connection will be encrypted. This isn't totally secure (the binary component could be reverse-engineered by a determined hacker) but it will certain deter casual attacks. Note, however, that implementing, building and maintaining a binary component is significantly harder than the JavaScript equivalent.
An alternative would be to put the user through a one-time registration process when they install the extension. This could even happen in the background, and the user would get some credentials (e.g. a PKI key pair) at the end that they would use for subsequent communication with the server. If you're worried about people overusing the server, then presumably doing so via the extension wouldn't be great either. This way you can track the usage of each user (via the extension or not) and limit it as necessary.
In the end I don't think that there is much you can do. You could have a binary library in your add-on and call it via js-ctypes (it is easier to implement and maintain than a binary XPCOM component). But nothing will stop people from taking your extension and changing its JavaScript logic in any way that they like. You can make it harder by using some logic like this:
Client to server: "Extension version 1.2.3 wants to make a request."
Server to client: "Take your chrome://... file, bytes M to N, what SHA1 checksum do you get for them?"
Client to server: "SHA1 checksum is ..., please process URL ... now."
But this is also everything but fail-proof, it merely makes abusing your service somewhat harder. Same goes for automatic registration - if your extension can register then an attacker can create an account as well.
I'm trying to find my way around the OAuth spec, its requirements and any implementations I can find and, so far, it really seems like more trouble than its worth because I'm having trouble finding a single resource that pulls it all together. Or maybe it's just that I'm looking for something more specialized than most tutorials.
I have a set of existing APIs--some in Java, some in PHP--that I now need to secure and, for a number of reasons, OAuth seems like the right way to go. Unfortunately, my inability to track down the right resources to help me get a provider up and running is challenging that theory. Since most of this will be system-to-system API usage, I'll need to implement a 2-legged provider. With that in mind...
Does anyone know of any good tutorials for implementing a 2-legged OAuth provider with PHP?
Given that I have securable APIs in 2 languages, do I need to implement a provider in both or is there a way to create the provider as a "front controller" that I can funnel all requests through?
When securing PHP services, for example, do I have to secure each API individually by including the requisite provider resources on each?
Thanks for your help.
Rob, not sure where you landed on this but wanted to add my 2 cents in case anyone else ran across this question.
I more or less had the same question a few months ago and hearing about "OAuth" for the better part of a year. I was developing a REST API I needed to secure so I started reading about OAuth... and then my eyes started to roll backwards in my head.
I probably gave it a good solid day or 2 of skimming and reading until I decided, much like you, that OAuth was confusing garbage and just gave up on it.
So then I started researching ways to secure APIs in general and started to get a better grasp on ways to do that. The most popular way seemed to be sending requests to the API along with a checksum of the entire message (encoded with a secret that only you and the server know) that the server can use to decide if the message had been tampered with on it's way from the client, like so:
Client sends /user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad
Server gets all that, looks up user "123" in database, loads his secret key and then (using the same method the client used) re-calculates it's OWN checksum given the request arguments.
If the server's generated checksum and the client's sent checksum match up, the request is OK and executed, if not, it is considered tampered with and rejected.
The checksum is called an HMAC and if you want a good example of this, it is what Amazon Web Services uses (they call the argument 'signature' not 'checksum' though).
So given that one of the key components of this to work is that the client and server have to generate the HMAC in the same fashion (otherwise they won't match), there have to be rules on HOW to combine all the arguments... then I suddenly understood all that "natural byte-ordering of parameters" crap from OAuth... it was just defining the rules for how to generate the signature because it needed to.
Another point is that every param you include in the HMAC generation is a value that then can't be tampered with when you send the request.
So if you just encode the URI stem as the signature, for example:
/user.json == askJdla9/kjdas+Askj2l8add
then the only thing in your message that cannot be tampered with is the URI, all of the arguments can be tampered with because they aren't part of the "checksum" value that the server will re-calculate.
Alternatively, even if you include EVERY param in the calculation, you still run the risk of "replay attacks" where a malicious middle man or evesdropped can intercept an API call and just keep resending it to the server over and over again.
You can fix that by adding a timestamp (always use UTC) in the HMAC calculation as well.
REMINDER: Since the server needs to calculate the same HMAC, you have to send along any value you use in the calculation EXCEPT YOUR SECRET KEY (OAuth calls it a consumer_secret I think). So if you add timestamp, make sure you send a timestamp param along with your request.
If you want to make the API secure from replay attacks, you can use a nonce value (it's a 1-time use value the server generates, gives to the client, the client uses it in the HMAC, sends back the request, the server confirms and then marks that nonce value as "used" in the DB and never lets another request use it again).
NOTE: 'nonce' are a really exact way to solve the "replay attack" problem -- timestamps are great, but because computers don't always have in-sync timestamp values, you have to allow an acceptable window on the server side of how "old" a request might be (say 10 mins, 30 mins, 1hr.... Amazon uses 15mins) before we accept or reject it. In this scenario your API is technically vulnerable during the entire window of time.
I think nonce values are great, but should only need to be used in APIs that are critical they keep their integrity. In my API, I didn't need it, but it would be trivial to add later if users demanded it... I would literally just need to add a "nonce" table in my DB, expose a new API to clients like:
/nonce.json
and then when they send that back to me in the HMAC calculation, I would need to check the DB to make sure it had never been used before and once used, mark it as such in the DB so if a request EVER came in again with that same nonce I would reject it.
Summary
Anyway, to make a long story short, everything I just described is basically what is known as "2-legged OAuth". There isn't that added step of flowing to the authority (Twitter, Facebook, Google, whatever) to authorize the client, that step is removed and instead the server implicitly trusts the client IF the HMAC's they are sending match up. That means the client has the right secret_key and is signing it's messages with it, so the server trusts it.
If you start looking around online, this seems to be the preferred method for securing API methods now-adays, or something like it. Amazon almost exactly uses this method except they use a slightly different combination method for their parameters before signing the whole thing to generate the HMAC.
If you are interested I wrote up this entire journey and thought-process as I was learning it. That might help provide a guided thinking tour of this process.
I would take a step back and think about what a properly authenticated client is going to be sending you.
Can you store the keys and credentials in a common database which is accessible from both sets of services, and just implement the OAuth provider in one language? When the user sends in a request to a service (PHP or Java) you then check against the common store. When the user is setting up the OAuth client then you do all of that through either a PHP or Java app (your preference), and store the credentials in the common DB.
There are some Oauth providers written in other languages that you might want to take a look at:
PHP - http://term.ie/oauth/example/ (see bottom of page)
Ruby - http://github.com/mojodna/sample-oauth-provider
.NET http://blog.bittercoder.com/PermaLink,guid,0d080a15-b412-48cf-b0d4-e842b25e3813.aspx