JavaScript, often abbreviated as JS, is a high-level, interpreted programming language. It is a language which is also characterized as dynamic, weakly typed, prototype-based and multi-paradigm.
In the ever-evolving landscape of digital security, robust password management tools have become indispensable. Our password management application, designed to simplify and secure your online life, now comes with an enhanced feature – the ability to edit passwords with ease.
A password manager is an important security tool that allows users to store and manage their passwords without the need to remember or write them down in insecure places. In this article, we will explore the development of a simple password manager using the Flask framework and the InterSystems IRIS database.
Key Features
Our password manager application will provide the following key features:
In this article, we will cover the basics of topics listed below:
1. Routing in Flask Framework 2. Folder structure for a Flask app (Static and Template) 3. Getting and displaying data in the Flask application from IRIS.
I wrote a step by step tutorial in the qewd-howtos repository how you can write state of the art multi-page web apps with Node.js using a QEWD-Up WebSocket/REST api back-end integrated with a mainstream web framework like NuxtJS & Vue.js.
N.P.M. is a Project & Task Management app that uses InterSystems IRIS and Bootstrap 4.
No Project Mess is created to help developers and small business companies to reduce complexity in their daily problems, with a simple and intuitive projects and tasks management software.
It offers different views for your tasks, from a spreadsheet, kanban, calendar, or even Gantt!
NLP stands for Natural Language Processing which is a field of Artificial Intelligence with a lot of complexity and
techniques to in short words "understand what are you talking about".
And FHIR is...???
FHIR stands for Fast Healthcare Interoperability Resources and is a standard to data structures for healthcare. There are
some good articles here explainig better how FHIR interact with Intersystems IRIS.
Now available on Open Exchange is a library of third party charts available to use within DeepSee/InterSystems IRIS BI dashboards. To start, simply download and install, select the new portlet as the widget type, then select the chart type that you desire. If you don't find the type of chart you are looking for, you can easily extend the portlet to implement your desired chart type. These new chart types can be used within existing dashboards or you can create new dashboards using them.
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:
This is a quick note on what happens when, on your CSP page, you call a cache script which returns a %Boolean and store that value in a javascript variable.
When you call a script with language="cache" and returntype="%Boolean" from a javascript script, the return value is interpreted as a string, not as a boolean.
Here's an example:
A cache script that returns (in theory) a "false" value:
Recently I reread this article by @Bernd Mueller. It's about calling DELFATE function from zlib library. In this article I'll demonstrate several different approaches to callout libraries, we'll build the same functionality (compress function) in several different languages and compare them.
There's a new and exciting enhancement to QEWD that has just been released - it's an additional layer of abstraction known as QEWD-Up. QEWD-Up hides away all the mechanics of QEWD itself, allowing you to focus on just your REST APIs and the code that implements them.
Additionally, and importantly, QEWD-Up simplifies the maintenance of your REST APIs, allowing you (and others) to quickly and easily understand their life-cycle and implementation.
As a result of Evgeny's recent questions regarding the use of QEWD.js with IRIS in another post, I thought it would be a good idea to create a separate post focusing specifically on how to use QEWD.js to create REST APIs for IRIS.
QEWD.js is, of course, a Node.js framework, and all the REST API code can be written entirely in JavaScript.
Some time ago I got a WRC case transferred where a customer asks for the availability of a raw DEFLATE compression/decompression function built-in Caché.
When we talk about DEFLATE we need to talk about Zlib as well, since Zlib is the de-facto standard free compression/decompression library developed in the mid-90s.
Zlib works on particular DEFLATE compression/decompression algorithm and the idea of encapsulation within a wrapper (gzip, zlib, etc.). https://en.wikipedia.org/wiki/Zlib
One of the most important features during application development is the ability to debug your code easily. Because of the asynchrnous nature, a standard Node.js application server works single-threaded by default. When you are developing applications using an IDE like Visual Studio Code, you can very easily debug your Node.js process:
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:
Most frameworks support either REST or WebSockets, and don't make it easy to switch between the two, and/or support both styles of application at the same time. WebSockets offer many advantages over REST, eg:
- most benchmarks show WebSocket messaging to be significantly faster than over HTTP
In our last lesson, we added some formatting and validation to our Edit Widget form. So, now we are ready to add the ability to add new Widgets to our application. However, the great Widget Wars have come to an abrupt end, as Widget Direct has purchased its biggest competitor, WorldWideWidgets. In order to maintain some continuity, we need to display their catalog on our new application.
In our last lesson, we added a form to Edit our existing Widgets, and save them back to the server. However, our Form was not well structured and our Save button had no intelligence, and was not fully visible. So today, we will apply some Material components and Angular style to make the form more useful
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.
At the end of our last lesson, we ended with our page displaying a nice (but garish) Angular Material Toolbar, and our Widget data displaying in a list of Material cards. Our page feels a bit static, and we already know that the large number of Widgets that we will be dealing with will not be especially usable on a static list. What can we do to help?
By date.png)
Open Exchange app
.png)
