Front-end web development is the practice of converting data to a graphical interface, through the use of HTML, CSS, and JavaScript, so that users can view and interact with that data.
IRIS provides us with anti login CSRF attack mitigation, however this is not the same as a CSRF attack, as login attacks only occur on the login form. There are currently no built-in tools to mitigate CSRF attacks on api calls and other forms, so this is a step in mitigating these attacks.
See the following link from OWASP for the definition of a CSRF attack:
The Widgets Direct sample application highlights many aspects of how to use InterSystems technologies to build a modern web application. Features include:
The goal of this post is to discuss working with Websockets in a Caché environment. We are going to have a quick discussion of what websockets are and then talk through an example chat application implemented on top of Websockets.
This post is intended to guide you through the new JSON capabilities that we introduced in Caché 2016.1. JSON has emerged to a serialization format used in many places. The web started it, but nowadays it is utilized everywhere. We've got plenty to cover, so let's get started.
InterSystems products (IRIS, Caché, Ensemble) already include a built-in Apache web server. But the built-in server is designed for the development and administration tasks and thus has certain limitations. Though you may find some useful workarounds for these limitations, the more common approach is to deploy a full-scale web server for your production environment. This article describes how to set up Apache to work with InterSystems products and how to provide HTTPS access. We will be using Ubuntu, but the configuration process is almost the same for all Linux distributions.
Not everyone knows that InterSystems Caché has a built-in tool for code profiling called Caché Monitor.
Its main purpose (obviously) is the collection of statistics for programs running in Caché. It can provide statistics by program, as well as detailed Line-by-Line statistics for each program.
Using Caché Monitor
Let’s take a look at a potential use case for Caché Monitor and its key features. So, in order to start the profiler, you need to go to the terminal and switch to the namespace that you want to monitor, then launch the %SYS.MONLBL system routine:
This code snippet provides a ZEN page that downloads a stream from its database directly:
/// We assume that you have stored your data within this schema:
/// MyApp.Model.Storage: Filename,FileSize,Content,ContentType
Class zen.downloadStream Extends (%ZEN.Component.page,%CSP.StreamServer)
{
/// Wrapper to get the id of the download, we assume that the id is passed to this zen page
/// as a URI parameter, i.e.: MyApp.Downloads.cls?OID=1234
ClassMethod GetId()
{
Quit $Get(%request.Data("OID",1))
}
/// Set the appropriate header for the file.
ClassMethod OnPreHTTP() As %Boolean
{
Set tId = ..GetId()
If ##Class(MyApp.Model.Storage).%ExistsId(tId) {
Set tStream = ##Class(MyApp.Model.Storage).%OpenId(tId)
// You could "guess" the content type by its file extension
// or you can store it (before) in the database separately (like in this example).
// Set Extension = $Piece(tStream.Filename,".",$Length(tStream.Filename,"."))
// Set ContentType = ..FileClassify(Extension)
Set %response.ContentType = tStream.ContentType
Do %response.SetHeader("content-disposition","attachment; filename="_tStream.Filename)
Do %response.SetHeader("Content-Length",tStream.FileSize)
}
Else {
Set %response.Status="404 File Not Found"
Quit 0
}
Quit $$$OK
}
ClassMethod OnPage() As %Status
{
Set Download = ##Class(MyApp.Model.Storage).%OpenId(..GetId())
Do Download.Content.OutputToDevice()
Quit $$$OK
}
}
In our last lesson, we added a relationship between 2 persistent classes. We are clearly going to need to start creating REST Services to expose CRUD operations for each of these classes, but before we do that, we should really finish defining our linkages. We added code to our Widget toJSON to spool off related Accessory data, so we should really do the reciprocal and allow Accessories to return all Widgets that are compatible.
are you curious which topics we are going to cover at this year’s Global Summit? You have come to the right place! I will provide you with a sneak peek of what you can expect from the areas I am responsible for.
or "Didn't you say you would cover Persistent Objects in Part 5, Chris?"
Yes, that was the plan. This is a pretty important topic, so it get's its own Article
Up until now, we've display widget JSON that has been created by a basic loop. Clearly this isn't of much value. Now we have our stack connected together, and we can see that the data is flowing to the Welcome page, it's time to complete the stack and start feeding our service from "real" data.
In this article I would like to present the RESTForms project - generic REST API backend for modern web applications.
The idea behind the project is simple -after I wrote several REST APIs I realized that generally, REST API consists of two parts:
Work with persistent classes
Custom business logic
And, while you'll have to write your own custom business logic, RESTForms provides all things related to working with persistent classes right out of the box. Use cases
You already have a data model in Caché and you want to expose some (or all) of the information in a form of REST API
You are developing a new Caché application and you want to provide a REST API
In our last lesson, we implemented a new REST Service to allow us to perform CRU operations on Widgets, and refactored our Controllers to allow the page setup to be decouple from the content.
I've mentioned the QEWD project in this group before: it's a Node.js-based platform for web, Native and REST applications which tightly integrates with Cache. It uses a somewhat different philosophy to the use of Node.js than the norm, and I've now published an article that explains this approach and the unique benefits that arise as a result.
It turns out that, integrated via QEWD, Cache is an ideal bed-fellow for Node.js. QEWD makes the integration of Cache and Node.js exceptionally fast, simple and intuitive to use, but also extremely powerful.
a.k.a.. "The World of Widgets Returns!" or "Paternity leave damages Instructional Series momentum"
In our last lesson, we combined 2 separate classes to appear as the same property. We now have the ability to Update our Widget catalog, but what if we want to Create a Widget? Thankfully, we've already done 90% of what we need, just by implementing Edits
In my previous posting about the new support in QEWD for JSON Web Token (JWT) support, I mentioned that it was a key step in enabling Micro-Service support in QEWD. In this post I'll give some background to how they work and the thinking behind them.
If you haven't heard about Micro-Services and/or want to learn more, there's lots of information available if you do a Google Search. Here's a good starting point:
If you read my previous post that introduced QEWD Micro-Services, you're hopefully eager to learn how to use them. So in this post I'll explain what you need to know in order to get started.
If you look in the QEWD repository, you'll find the folder:
In our last lesson, we implemented a linkage to our WidgetAccessory class, and debugged some errors we encountered along the way. We now have our data being returned by REST, but what if we want to update or add new data to our application?
We left our application over the weekend, secure in the knowledge that it was returning data from our primary persistent class, User.Widget. However, Widgets Direct are the premier supplier of both Widgets AND Widget Accessories, so we should really start working on adding these Accessories to our application.
By update
Open Exchange app
