Download the PHP package userfrosting/fortress without Composer

On this page you can find all versions of the php package userfrosting/fortress. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package fortress

Fortress 4

Latest Version Join the chat at https://chat.userfrosting.com/channel/support Donate

Branch Build Coverage Style
master
develop  

If you simply want to show that you like this project, or want to remember it for later, you should star, not fork, this repository. Forking is only for when you are ready to create your own copy of the code to work on.

By Alex Weissman

Copyright (c) 2015-2019

A schema-driven system for elegant whitelisting, transformation and validation of user input on both the client and server sides from a unified set of rules.

Introduction

Data from the outside world is the Achilles' heel of modern interactive web services and applications. Code injection, cross-site scripting (XSS), CSRF, and many other types of malicious attacks are successful when a web application accepts user input that it shouldn't have, or fails to neutralize the damaging parts of the input. Even non-malicious users can inadvertently submit something that breaks your web service, causing it to behave in some unexpected way.

For the sake of both security and quality user experience, it is important for a web developer to do two things:

  1. Decide exactly what type of input your application should accept, and;
  2. Decide how your application should behave when it receives something that violates those rules.

Sounds simple, right? Unfortunately, even experienced developers often slip up, allowing a malicious user to execute SQL or PHP on the application's server (or, in the case of XSS and CSRF attacks, allow a user to trick other users into executing malicious code).

Part of the problem is that this kind of filtering must be done at every point in the application where the user can submit raw data to the server. A modern web application might accept hundreds of different types of POST requests, and it can become extremely tedious to code the rules for each request manually. Much of this work must also be done on both the client side (for user experience) and the server side (for security).

Fortress solves this problem by providing a uniform interface for validating raw user input on both the client side (in Javascript) and on the server side (in PHP) using a single unified set of rules. All you have to do is create a request schema, which defines what fields you're expecting the user to submit, and rules for how to handle the contents of those fields. For example, you might want to check that an email address is well-formed. The request schema, which is simply a YAML or JSON document, makes it easy to manipulate these rules in one place.

The request schema can be applied on the server side to received request data, but also be transformed to formats compatible with client-side validation libraries such as the jQuery Validation plugin, making it easy to perform client- and server-side validation without having to write every rule twice.

An example request schema, written using the WDVSS standard:

schema.yaml

Dependencies

Installation

To install with composer:

  1. If you haven't already, get Composer and install it - preferably, globally.
  2. Require Fortress, either by running php composer.phar require alexweissman/fortress, or by creating a composer.json file:

and running composer install.

  1. Include the vendor/autoload.php file in your project:

Usage

Request schema

To read a YAML or JSON schema, use a YamlFileLoader:

To use it, it must be read and loaded into a RequestSchemaRepository object:

You can add additional validation rules to a schema at runtime, if you wish:

Data transformation

The data transformer performs the following tasks:

  1. Whitelisting of input array against the schema. By default, any parameters not listed in the schema will be filtered out. Other options are "error" and "skip".
  2. Perform a series of transformations on the input data. For example, trim or purify.
  3. Set any default values for fields in the schema which are not present in the input array.

Server-side data validation

To process an array of user input, create a ServerSideValidator object with the schema and a translator object.

Translator object

Fortress requires a Translator (see i18n) object to translate message keys that may appear in rules:

Then, call validate on the input array. validate will return false if any of the rules are failed. Call errors to get the list of generated error messages. You might want to store these error messages to a flash messaging system so they can be shown to the user.

Client-side data validation

When generating a page or form, you will use one of the Adapter classes to generate a compatible set of rules from your WDVSS schema:

Add Namespace to the validation field names

You can also add an array prefix to the field names to generate validation rules for the input schema that will wrap all the field names with the namespace of the form for which the validation rules are being generated.

This will generate validation rules with field names mycoolform1[<fieldname>] : { .... } instead of <fieldname> : { .... }

This comes in handy when you are generating validation rules for multiple forms or form sections on the same page

Message keys

The message for a rule can be either a plain string, or a translatable message key.

In the definitions of translatable message keys, the keyword "self" is reserved to refer to the name of the field being validated. Thus, a message like this:

"MIN_LENGTH" => "The field '{{self}}' must be at least {{min}} characters long"

for a field defined as:

Would translate to:

"The field 'tagline' must be at least 10 characters long"

Limit rules to server or client only

Sometimes, you only want a validation rule to be applied server-side but not in Javascript on the client side, or vice versa. For example, there may be forms that contain hidden data that needs to be validated on the server-side, but is not directly manipulated by the user in the browser. Thus, these fields would not need client-side validation rules.

Alternatively, there might be fields that appear in the form that should be validated for the sake of user experience, but are not actually used by (or even sent to) the server.

To accomplish this, each validation rule can now accept a domain property. Setting to "server" will have it only applied server-side. Setting to "client" will have it only appear in the client-side rules. If not specified, rules will be applied both server- and client-side by default. You can also set this explicitly with the value "both".

Style Guide

Testing


All versions of fortress with dependencies

PHP Build Version
Package Version
Requires ezyang/htmlpurifier Version ^4.7.0
php Version >=7.1
userfrosting/i18n Version ~4.5.0
vlucas/valitron Version ^1.2.3
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package userfrosting/fortress contains the following files

Loading the files please wait ....