Skip navigation

Jive Developers

1 Post authored by: george.burri

headline.pngAs a member of the Jive Security Team, I am committed to keeping our customers safe from the latest threats. Part of the daily responsibilities of my team and I include reviewing reports generated by our security tools, including event loggers, the intrusion detection system, application scanners and network scanners. With all these tools in place, you could imagine that I would spend a significant amount of time logging into each tool every week, setting the report parameters, waiting for the reports to download, then uploading them into our internal Jive community, so that I could review and discuss the findings with my team. Obviously, this was a problematic time sink for my team and I, especially in a field where agility is key!

 

Being an Engineer, I knew there was only one solution to this problem: automation. I found inspiration in another team that had built an automated mechanism that reported application build statuses directly in the community. This is exactly what I needed for my tools: a seamless way to get information directly into Jive without any manual steps. What was their secret? The Jive API of course! A quick search of our documentation led me to the Jive REST Rest API v3.6 → Content service; using this service, it's possible to push files right into Jive, which fit my use case perfectly.

 

Now that I had my API hook, I just had to build an automation script around it. I decided to use Python as my language of choice, as its flexibility allowed me get the script written quickly and easily. The first step was to write methods for grabbing the report files out the various tools we use. I won't go into detail on that here, as the methods vary widely per tool (SSH, CURL, APIs, and email were all used). Then there was the small detail of architecture; this script needed to run somewhere, so I setup a virtual machine inside of our tools environment.

 

To give you a rough idea of the end architecture, here's a simple diagram:

Jiveservers.png

After that was complete, it was all just matter of hammering out the fine details of what I wanted to do with the reports in Jive.

 

That's where it all came down to one line of code:

os.popen("curl -u "+username+":"+password+" --form \"content={'parent':'"+communityURL+"/api/core/v3/places/"+placeID+"','content':{'type':'text/html','text':'<body>"+bodyText+"</body>'},'subject':'"+subjectText+"','type':'file','visibility':'place'};type=application/json\" -F 'file1=@"+filepath+";filename="+filename+"' '"+communityURL+"/api/core/v3/contents'")

 

So as you can see, I making a call to the system CURL to execute the REST call; one may argue that I should have used Python's native CURL library, but I went this route as it's easier to debug. The call is parameterized, making it highly reusable. Let's break down the key parts of this call:

  • -u "+username+":"+password+" - The credentials being passed for authentication. We created a new a "security reports" user in our community specifically for this script. As as security guru, I must remind you not to store credentials in the script, but rather, put them in a separate, read protected location.
  • 'parent':'"+communityURL+"/api/core/v3/places/"+placeID+"' - The place where the file should be posted. The placeID is the number that can be found in the URL of a group or space.
  • 'text':'<body>"+bodyText+"</body>' - The content that appears above the file preview in Jive. It can be optionally left blank.
  • 'subject':'"+subjectText+"' - The name of the document used in Jive. Note that it must be unique within the space, or else this call will fail.
  • 'type':'file' - Specifies the content type. In this case, we're using file, but can changed to create another type, such as a document.
  • 'visibility':'place' - Means that it will only be visible to people who can access the place where it's stored.
  • file1=@"+filepath+" - The path to the file within the local file system.
  • filename="+filename+" - The name of the file as it will appear when downloaded from Jive.
  • '"+communityURL+"/api/core/v3/contents' - The URL of the API service where the post is sent.

 

Now with the script ready to go, I promptly set up some CRON jobs to fire it every week. The jobs are separate for each tool, as each one has a slightly different schedule in regards to when new reports are available. Now at the scheduled time intervals, the reports appear in Jive!

 

Having our reports automatically uploaded has had several key benefits for our team:

  • Many of the files are too large for email, and would otherwise be very difficult to share.
  • Having them in Jive allows us to easily discuss them, link to them, search them, and bring in other teams when needed.
  • No more time is wasted waiting for report generation and download.
  • Jive serves as a redundant backup, and easy to access archive for these reports.
  • We can keep tighter controls on who can access our tools, since non-administrative users can view the data they need right in Jive.

 

While I have spotlighted only one potential use of this API capability, the possibilities are endless. One team within Jive use this to upload daily production monitoring data, while other team has designed an "org chart" user that posts whenever employees in the company join, leave, or are promoted. Such novel uses will help you and your company get the most out of the Jive platform, deriving extra value through minimal development work.

 

What do you think about this simple integration? 

How can you extend this example to meet your needs? 

Do you have any suggestions for improvement?

 

George Burri

Security Engineer

Jive Software

Filter Blog