One of our clients recently had a unique use case. They had a Wiki site where they wanted to restrict viewing of posts to only their app’s authorized users. Picture something like a SaaS app where the Wiki site had proprietary content that our client only wanted paying users to access.
The two obvious options to implement this would be:
Create a Wiki user for each authorized user – this has the downside that we’d need to maintain two accounts, figure out how to keep users logged into both, and deal with synchronizing account data.
Modify the Wiki’s application code to authorize the users in some fashion – this is problematic because it would make upgrading the Wiki software difficult.
Turns out there’s a third option which is much smoother! Nginx has a directive called auth_request which allows nginx to authorize access to a resource based on a 2nd HTTP request.
The way it works is:
Your SaaS app is setup at platform.setfive.com where users are authenticated by a Symfony application.
You configure your Symfony application to send a cookie back with a wildcard domain of “.setfive.com”
Your wiki is running at wiki.setfive.com and configured to authorize requests to platform.setfive.com/is-authenticated
Now, when users request wiki.setfive.com their browser will send your Symfony authentication cookie, nginx will make a request to platform.setfive.com/is-authenticated, and if they’re authenticated they’ll be granted access to your wiki.
The nginx config for this is pretty straightforward as well. One thing to note is this module is not standard so on Ubuntu you do need to install the nginx-extras package to enable it.
For many applications a security and authentication scheme centered around users makes sense since the focus of the application is logged in users taking some sort of action. Imagine a task tracking app, users “create tasks”, “complete tasks”, etc. For these use cases, Spring Boot’s Security system makes it easy to add application security which then provides a “User” model to the rest of the application. This allows your code to do things like “getUser()” in a Controller and have ready access to the currently authenticated user.
But what about applications that don’t have a user based model? Imagine something like an API which provides HTML to PDF conversions. There’s really no concept of “Users” but rather a need to authenticate that requests are coming from authorized partners via something like an API key. So from an application perspective you don’t really want to involve the user management system, there’s no passwords to verify, and obviously the simpler the better.
Turns out its very straightforward to accomplish this with a Spring managed Filter. Full code below:
The code is pretty straightforward but a couple of highlights are:
It’s a Spring Component so that you can inject the repository that you need to check the database to see if the key is valid
It’s setup to only activate on URLs which start with “/api” so your other routes wont need to include the Key header
If the key is missing or invalid it correctly returns a 401 HTTP response code
That’s about it! As always questions and comments welcome!
Amazon Web Services recently published an E-Book on modern application development. In short, this guide explains the significance of digital transformation and how it can reinvent how your business delivers value. The main topics covered include: Digital Innovators, Characteristics of Modern Applications, Data Management & Computing in Modern Applications, and Security & Compliance. Below, I have summarized a few takeaways from each topic.
Digital Innovators
To be a digital innovator, you must work backwards to understand that innovation starts with your customers and listening to their wants and needs. AWS calls this process the “innovation flywheel.” The innovation flywheel consists of three steps: listen, experiment, iterate. After putting your customers first, it is essential to put technology at the center of your business. Some ways to do this are through digital marketplaces (two sided market that connects buyers and sellers,) direct-to-customer engagement, digital products as services, and insight services.
Characteristics of Modern Applications
Modern application development is a powerful approach to designing, building, and managing software in the cloud. Characteristics of Modern Applications align with digital innovation (see above.) Modern Applications require a culture of ownership, which also starts with the customers. To create this culture, companies should hire builders and support them with a belief system and let them build. It is important to trust in others skill sets and know where your boundaries lie. In terms of the architectural patterns of modern applications, most are micro-services. Micro-services have minimal function services, are deployed separately but interact together, each has its own datastore, is organized around business capabilities, the state is externalized, and provides a choice of technology for each micro-service.
Data Management & Computing in Modern Applications
Data management refers to purpose built databases that serve as decoupled data stores. Data management includes computing in modern applications. Computing with micro-services effect the way you package and run code, and compute in modern applications such as AWS Lambda. Release pipelines in AWS are standardized and automated. This means that they are no longer manual, there is continuous integration and continuous delivery. Also, there is a server-less operational model. These models are ideal for high-growth companies that want to innovate quickly because they don’t require server management, they provide flexible scaling, you pay for the value you need, and they automate high availability.
Security & Compliance
Security configuration and automation are needed. To ensure security and compliance, these practices are incorporated within the tooling. Some of this tooling includes code repositories, build-management programs, and deployment tools. Security and compliance are also applied to the release pipeline itself and the software being released through the pipeline. Lastly, DevOps and DevSecOps safeguard security and compliance. AWS defines DevOps as, “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.” Similarly, DevSecOps is described as “philosophy of integrating security practices within the DevOps process. DevSecOps involves creating a “Security as Code” culture with ongoing, flexible collaboration between release engineers and security teams.”
I hope that you found these summary useful. We will continue to try to summarize AWS content so that you don’t have to read it or navigate demo vids / webinars. Like what you read? Check out our blog post on why AWS is so cool: https://shout.setfive.com/2019/07/11/what-makes-the-aws-cloud-so-cool/.
Even in 2019, software testing is still a challenge for a lot of small companies. Testing is usually not prioritized amongst small teams. Small teams frequently lack a dedicated QA resource, this causes writing good tests to be a unique skill in itself. Because of this, teams will end up with maturing software products that have few or no tests. As development continues, the downside is that there is an increased potential for bugs to enter the product. So, how can small teams tackle this challenge? As the software development industry has evolved, the industry has developed a wide array of quality assurance (QA) tools and techniques. Broadly, these tools can be categorized into two buckets – manual (human) testing and automated testing.
Manual / human testing is essentially exactly what it sounds like. A human QA engineer manually executes a list of steps, evaluates the results, and decides if the tested software is passing. Manual testing is relatively easy to start because non-technical resources can develop and execute the tests. However, as the test suite grows, teams run into issues because they’re limited by how many QA resources they have. This leads to teams only running tests before certain deployments, causing them to miss bugs.
In contrast to manual testing, automated testing is typically entirely code based. A QA engineer writes tests in a general purpose programming language. This asserts that the tested software is still working as anticipated. Since the tests are executed by a computer, this approach does not suffer from the limitation highlighted above. The trade off is that, because the tests are written in a programming language, technical resources are required to develop the tests.
So, what if there was a hybrid approach that combined some aspects of each approach? Well, that’s why you’re here! Say hello to RainforestQA.
What is RainforestQA?
RainforestQA is a SaaS product that incorporates manual and automated software testing approaches. RainforestQA offers a free trial, followed by a pay-as-you-go billing model, where you only pay for the resources being used. RainforestQA tests are executed by an automated system, or human testers, depending on how the test is constructed.
What does an automated RainforestQA test look like?
The tests are composed of a series of steps, which describe actions or assertions, that the automated system must take. The steps can include, “load this page” or “scroll the page down,” while the assertions are things like, “see a button” or “confirm text on the page.” When any one of these steps / assertions fail, the entire test fails, which indicates that something is broken in the software being tested.
What’s the process of building these automated tests?
Building automated tests on the Rainforest QA differs depending whether it is written in Plain English or Beta Language. When constructed in English, the user is constructed to write their own question and answer for each step. If the test is written in Beta Language, an action can be selected from the sidebar on the right, followed by a target, which is also listed on the same sidebar. The types of actions and targets can be adjusted depending on the test and what is being assessed.
When composing certain tests in Beta, you will find that the same sequence of steps are needed. Instead of writing out every individual step, over and over, the “custom actions” feature can be used. This feature enables a series of steps to be grouped together, which saves a lot of time and energy. I found the custom actions feature exceptionally useful when a login was required at the beginning of the test. However, a flaw in this feature can appear if the actual custom actions, itself, is being tested. The test results for a custom action will not appear unless the results page is reloaded. While this is a very small detail, it was a fairly substantial inconvenience for me. The rest results appeared as though the custom action test was in progress for over an hour, when in actuality, the test results were returned within a few minutes, they just did not appear until the page was refreshed.
How does the back-and-forth work between users and Rainforest QA engineers?
When running a test, everything is sent through a real and active test team of almost 60,000 testers. The test team provides clear feedback in a timely manner. If the test is passed, it will appear in green (as pictured above.) If the test is failed, it will come back in red. If the “Go To Test” button is selected, the test feedback can be viewed. Specific comments and critique are given on the particular step that caused the test to fail. Additionally, all of the tests and results are automatically recorded and stored in a neat and orderly fashion.
What is the Difference Between Testing Languages?
As discussed, on the Rainforest QA, tests can be written in “Plain English” or “Beta Language.” Writing tests in plain english is faster and easier, but also much more expensive. For a test to be passed in “Plain English,” the tests have to be written and constructed in a very specific way. For example, if you wanted to test the login page while leaving the username or password blank, you cannot use the “type” action to exemplify that you are leaving it empty. With the Beta Language tests, you have to select a specific action from the bar on the right, followed by a target. The only choices are what is already listed. In Beta, you have the option to use custom actions, you can also make new targets, but only by labeling a pre-existing type of target. When conducting a test in beta language, screenshots are used to identify what should be seen/clicked on each page. The downside being, if there are three of the same buttons on one page, you cannot type in directions, nor can you describe which of the three identical buttons needs to be selected.
Conclusion
I haven’t plugged Rainforest into our development workflow, so I cannot speak on the integrations or reporting. However, I would recommend the Rainforest QA to anyone- regardless of their technical ability- that wants to run automated tests on a timely and inexpensive budget. Building tests on this QA very quick and straightforward. While you may find a few complications and specificities on each language, it typically would not take more than one revision to fix the issue.
TL ; DR
Likes:
Interface is easy to use
Variety of features available to test
Access to a test team that provides feedback quickly
Non-technical users can build tests and test the UI without writing code
Free trial and then pay as you go pricing
Custom actions
Dislikes:
Tests written in Plain English language ask for specific answers on tests which allows a huge margin for error including spelling, spacing, and plurals
Have to be written and constructed in a very specific way to be passed and you can’t use any screenshots to clarify directions
Screenshot feature for capturing targets do not always capture / appear
The following article is the first part of a series on HIPAA and its impact on certain industries in the United States. This piece aims to define HIPAA, identify 2019 HIPAA regulations and violations, and explain HIPAA compliance. Hopefully, this read will be informational, and especially useful, if you are unfamiliar with HIPAA and it’s applicability. The importance of HIPAA (Health Insurance Portability and Accountability Act) has recently hit the U.S. headlines as a trending topic. Particularly, the impact of HIPAA in the healthcare space has circulated throughout the U.S. media. HIPAA compliance recently became a point of emphasis when the United States government made changes to the act, and its surrounding enforcement, in 2019. While HIPAA was enacted over 23 years ago, the significance of this act has evolved as western society has become increasingly involved with- and dependent upon- technology. When initially implemented, HIPAA served to protect personally identifiable information maintained by healthcare companies.
2019 HIPAA Regulations and Violations
In December 2018, the OCR (Office of Civil Rights) issued a request for information to HIPAA covered entities. The OCR was specifically focused on the current Privacy Rule to confirm that HIPAA was not prohibiting, nor discouraging, any patients from proper care. To instill safety and protection over access to patient’s rights and information, the OCR plans to increase enforcement around the Privacy Rule. The OCR is also optimistic that emphasis on HIPAA compliance will help to fight the opioid crisis in the United States. Additionally, the OCR is concerned with the number of email data breaches due to the major problem of phishing in the healthcare industry. If a company is caught in a violation of HIPAA, or fails to comply, they can be faced with serious fines and even incarceration. To ensure that this does not happen, there are a few fundamental precautions healthcare companies can take to warrant compliancy.
Maintaining HIPAA compliance
To guarantee HIPAA compliance, the first preventive measure every company must take is training their employees on HIPAA compliance. By educating an organization on the dangers of using PHI information for personal benefit, the chance of an accidental HIPAA violation can be greatly minimized. It is crucial for healthcare companies to implement policies around the hardware and electronic services that they share with their business associates. To do so, risk management assessments can be performed on security and storage measurements. A majority of recent HIPAA violations have stemmed from the way patient data is being stored, additionally, there are release forms patients must be provided to sign off on the disclose the use of their personal health information. Some practices failed to distribute updated release forms. By administering mandatory notices, and operating with patient consent, in writing, a large portion of ambiguity and uncertainty around HIPAA compliance can be waived.
Industries Impacted by HIPAA
Over the past twenty years, medical records have been transferred from paper to wireless systems, enhancing the need for IT software and applications. As the demand for IT systems to collect and store data grows, the risk of cyber-attacks presents itself. Since data in the health industry is stored on servers, and not in a cloud, IT providers, as well as mobile application companies, also become liable. Some effective practices to prevent data hacking and fraud include: audits, encryption, data breach notifications, and a recovery plan. In regards to software development, some necessary features to consider are: access control, authorization, and backup data.
HIPAA Enforcement
Last year was a record year for HIPAA enforcement. With total fines and settlements reaching over 28 million dollars, healthcare companies have a lot to think about. Ultimately, it is critical to be educated on HIPAA and how to maintain HIPAA compliance. Whether it is negligence, lack of information, or an unfortunate security hack, even companies in cohesion with the health industry can be liable for a HIPAA violation. Stay tuned for our next blog post as we delve into HIPAA in our local sector of Boston, MA.
