I am building a webpage to be embedded as an Iframe App within Connections Cloud. It is based on the principals from this tutorial.
The webpage will be hosted on a server outside (of course) the collabserv.com domain. The purpose of the webpage is to interact (read/write) with Connections Cloud, using the SBT SDK, on behalf of the current Connections Cloud user.
The user is already authenticated with Connections Cloud, so I would not like there to be an extra login every time the Iframe App is loaded (making calls to Connections Cloud).
Since my webpage is located outside the Connections Cloud host/domain, it's not possible to reuse the user's existing authentication with the Connections Cloud server (?).
Any suggestions for solutions or workarounds?
BTW, my webpage will be hosted on a Domino server, but ideally there will be no user accounts on this server.
I was able to establish an authenticated connection with Connections Cloud using OAuth2. I more or less followed the OAuth2-steps described by Paul Bastide in this article.
All operations from start to the point where "code" is returned, are handled with XPages, reading QueryString for parameters etc. From that point (starting with "Open a Terminal Window" in the article), I programmed a Managed JavaBean that handles the rest of the OAuth-dribbeling.
When the access_token finally is received in my JavaBean, I use that to build a "Bearer authorization header" for an Apache HttpGet object. I then use the HttpGet object to query the Connections Cloud REST APIs.
Related
I have an API set up on my server (node.js) which potential clients can send request to. One such client would like for me to set up a structure where they would pay only for the amount of their users who would connect to my API. They are creating a mobile application. Regardless mobile or web, I'm not sure how I would be able to track their individual users, to make sure it is their users who are sending requests to my server and not the client himself. The client can make one request and send to 1000 of their users instead of 1000 of the client's users directly connecting to my server.
The only feasible solution I can think of is creating a plugin which they would insert into their app and it would connect directly to our server, bypassing the client's server. Something like a Facebook Share/Like, Google +1 button. Creating the plugin would require to create the entire request and dynamic layout in each platform language, which is outside my scope at the moment.
Is there any way to have the end-users connect directly to my server through the client's app, bypassing the client in the middle, allowing me to know how many users will be connecting?
Using the IBM SBT, one can easily register and endpoint to connect to IBM Connections Cloud. That way it is easily possible to access the APIs provided by IBM Connections using a local URL that is then proxied to the cloud.
Usage can be done using the provided JavaScript or by just requesting a resource from the locally provided endpoint that is connected to the cloud. While this appears to be working for the vast majority of the documented APIs, it does not for the OEmbed API.
Example: If you have a local Java App Container (like IBM Websphere Liberty Profile) that is running a testapp and has a configured endpoint to your Connections Cloud Organization, you may ask that endpoint to retrieve the users profile service document by requesting: https://localhost/testapp/service/proxy/localhost/profiles/atom/profileService.do.This will retrieve the very same resource as you would receive if you request https://apps.na.collabserv.com/profiles/atom/profileService.do directly.
Other APIs work similarly. Unfortunately the OEmbed API does not. That means, if one would request https://apps.na.collabserv.com/connections/opengraph/form/anonymous/api/oembed?maxHeight=180&maxWidth=180&extended=true&url=http%3A%2F%2Fwww.ibm.com the server returns some JSON as described in the spec. In the same seting as above, a call to https://localhost/testapp/service/proxy/localhost/connections/opengraph/form/anonymous/api/oembed?url=http%3A%2F%2Fwww.ibm.com&maxHeight=180&maxWidth=180&extended=true should return the same result but isn't. Instead the server returns an Error 403: SRVE0295E: Error reported: 403 with a HTTP Status 403.
The response is by the way the same result as one would get if he was trying to use the direct URL unauthenticated against the cloud.
Is there anything that needs to be configured in order to use the OEmbed service via SBT?
I'm planning on making an android application that sends user data to a web server and stores it temporarily in a database. Now I've never worked with databases or web servers before, but after reading a bunch of tutorials and a few days of hacking away I managed to get a node.js server with mongodb up and running on the openshift platform.
Right now anyone can interact with the database just by sending a GET request or even just pulling up the url in a browser. Is there a way to prevent that by happening or would I have to maybe encrypt the data myself before storing it?
You describe a typical web application using REST APIs. To secure it, do two things:
Deploy your REST APIs (or the entire site) using HTTPS instead of HTTP. This provides end to end encryption so your sensitive data cannot be viewed while in transit
Add an authentication and authorization mechanism, so that only authenticated endpoints can access your REST APIs.
I am using Nodejs,expressjs,and mongoose to develop a application.Now what is procedure or way to identify that the request hit of my rest api service is from my front end application not from any unknown request.
If your front end application is a browser web page, then there is no real way to limit your REST API service to only your web app.
The issue is that by its very nature the REST API service is available on the web to any client that wants to access it. You could add some authentication (some sort of secret key) that is required before the REST API service can be accessed, but you cannot hide that secret key in a browser web page. If the browser web page can get access to the key, then so can anyone else who looks at the code in the web page or on the wire.
Because browsers, by default, will not allow cross origin Ajax calls, you are already protected from some other web pages (on a different site) using your REST API service from the browser. But, other servers can still use your REST API service.
One common way that services attempt to manage the use of their APIs is that they require an API key be obtained for each legitimate use of the API. If a particular API key is found to be abusing the service, you can revoke the privileges of that API key. You can grant your own applications API keys (embedded in your web pages ) and you can even change those web keys regular (such as daily) to keep people from copying them once and then using them for a long time. But a determined hacker will still find a working API key and use it for awhile.
One common way that services attempt to prevent excess usage of their API and protect the integrity of their service is to implement rate limiting. You establish what you think is a reasonable number of API calls per second (or some such metric) that your own app would not exceed and you measure the number of API calls coming from each endpoint and if they exceed some threshold, then you either delay or deny or error their calls until they stop exceeding your threshold.
I am creating a web application that uses the Drupal 7 Content Management System. The web pages heavily use JQuery and AJAX.
The AJAX calls hit REST services, which are actually implemented using JAVA. Apache is running Drupal 7 and is configured to pass any calls to the REST urls through to the Java EE server (Jboss AS7). Everything is over SSL.
I need to Authorise and Authenticate calls to the REST services, and access the username or ID of the person currently logged-in to Drupal from the Java app. The question is... how...
As the AJAX calls are made to the same Apache server (rather than to a separate server etc), everything happens within the same http session, so I'm hoping this will be quite easy.
Things I've thought-of:
Configure a java security interceptor that calls a custom (locally
accessed only) drupal service that somehow reads the session id and
returns the logged-in username
create a "dumb" drupal REST service to act as a gateway for all of my REST calls, which authorises/ authenticates then injects the username before passing-through to the Java backend service
The article at https://lists.wisc.edu/read/messages?id=7777296#7777296 made me wonder if I could get-away with calling a Drupal service (just at the start of each Java service session) that takes a Drupal sessionID and returns the current user and his roles. I could configure it in my Java service so it would reperform this call every x seconds or y calls to check for role changes or logouts.
How does everyone else do it? This must be a common problem to solve isn't it? If not, what do you do instead to securely access authenticated services over AJAX? I'd rather not introduce a second user control process in addition to Drupal unless it's unavoidable. DRY :)
Thank you - this has me stumped!
Looking at what you are doing and trying to keep things as simple as possible, I would go for a variation of the first option. This is basically what the current node.js module does although it does it with unique authorization tokens. The workflow is something like this:
When a logged in user loads a page, a unique token is generated and stored in the Drupal database and sent to the browser
When the browser goes to connect to the node.js server it sends the auth token along with the request
The node.js server, upon receiving the request with token for the first time, will connect to a web service on the Drupal site and verify that the token is valid and send back any info about the user, and what roles/etc they have.
The node.js server then stores this internally for future requests, so that it doesn't have to ping the Drupal site for each request.
When a user logs out of Drupal, Drupal makes a direct request to the node.js server asking it to delete the token for that user.
Sounds like basically swapping your java app for node.js this should be pretty doable, with the advantage that it can scale well if you split this to multiple servers in the future.