Tuesday, February 28, 2017
Snarkdown – Simple Markdown Parser with Javascript
Snarkdown is a dead simple and lightweight Markdown parser written in JavaScript.
It's designed to be as minimal as possible, for constrained use-cases where a full Markdown parser would be inappropriate.
by via jQuery-Plugins.net RSS Feed
How to Secure Laravel Apps with 2FA via SMS
While everyone is concerned about their application's security, few take it seriously and take the plunge. The first thing you'll notice when learning about this is that two factor authentication (2FA) is the go-to solution as a first step.
Although there have been some serious problems with using text messages as a second factor, it's definitely safer than a plain username and password combination, given that many users tend to use popular and easy to guess passwords for critical services such as payments, chat, emails, etc. In this article, we're going to build two factor authentication into a Laravel application using Twilio SMS as the second factor.
What We're Building
There's a great chance that you're already familiar with the 2FA flow:
-
User visits the login page.
-
He types in an email and a password.
-
We send a verification code using the phone number.
-
User must type in the received code.
-
If the code is correct, we log them in. Otherwise, we give them another chance to try logging in.
The final demo application is up on GitHub.
Installation
I assume you have your development environment already set up. If not, we recommend Homestead Improved for an easy start.
Go ahead and create a new Laravel project using the Laravel installer or via Composer.
laravel new demo
Or
composer create-project --prefer-dist laravel/laravel demo
Edit the .env file and add your database credentials.
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=root
DB_PASSWORD=root
Scaffolding Authentication
Before creating our migrations, keep in mind that Laravel has a command to help us scaffold our authentication flow. It generates the following:
- Login, register and reset password views and controllers.
- The necessary routes.
Go ahead and run php artisan make:auth from the command line.
Creating Migrations
Update the users migration class and add a country_code and phone fields.
// database/migrations/2014_10_12_000000_create_users_table.php
class CreateUsersTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->string('email')->unique();
$table->string('password');
$table->string('country_code', 4)->nullable();
$table->string('phone')->nullable();
$table->rememberToken();
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('users');
}
}
Every user has a list of tokens (verification codes) that they generated. Run the php artisan make:model Token -m command to generate the model and migration file. The table schema will look like this:
// database/migrations/2016_12_14_105000_create_tokens_table.php
class CreateTokensTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('tokens', function (Blueprint $table) {
$table->increments('id');
$table->string('code', 4);
$table->integer('user_id')->unsigned();
$table->boolean('used')->default(false);
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('tokens');
}
}
I limited the verification code to four digits, but you can make it harder to guess by increasing it. We will get back to this point later. Let's run php artisan migrate to create our database.
Continue reading %How to Secure Laravel Apps with 2FA via SMS%
by Younes Rafie via SitePoint
Low-Code Mobile Basics with OutSystems
This article was sponsored by OutSystems. Thank you for supporting the partners who make SitePoint possible.
If you've never heard of low-code before, join the club. In July of 2016, OutSystems asked me to review a pre-release version of their low-code tool. I had no clue what low-code was or why these people were even talking to me.
Turns out that low-code platforms are essentially drag-and-drop IDEs. They're designed to help developers breeze past a ton of boilerplate work and focus on the meat of their web products. And OutSystems was about to upgrade their offering to include mobile applications.
They reminded me that I was a native mobile developer, and that's when it clicked. They wanted to know if their platform held up to snuff. Suffice it to say that while I enjoyed the speed of low-code, I found a lot of questionable omissions from their product as well as performance issues.
They worked their asses off to make improvements in time for the release, and sorted out a lot of my original concerns. I was, and still am impressed with the final product. And I wanted to show the SitePoint community how to accomplish common mobile patterns using a low-code platform like OutSystems.
While these techniques apply exclusively to OutSystems, competitors such as Mendix, AppGyver, and others offer similar features that loosely map to those you're about to see.
Set Up a Local Database
If you've worked with Core Data on iOS, then the low-code approach to ORM should feel familiar. For those on Android, if you're still writing SQL queries by hand, I've been there. I recommend trying ormlite, greenDAO, SugarORM, or something similar.
In low-code, your back-end and front-end merge into one editor, so they take care to delineate the boundary between cloud and local storage.
I created a database entity, Book, and populated it with some attributes. OutSystems generated CRUD actions for me automatically:
The orange circle icons represent server-side actions, and you'll see how they come into play later on. So, I have a Book entity that exists in the cloud and it can represent a single work with a title, author, and ISBN.
If you've been around the client-side block long enough, you know that clients don't replicate central databases. And they don't always require a mirror image of each model, either. Some data can remain on the server to reduce response sizes.
In OutSystems, I can create a local entity based on an existing cloud entity in two clicks. When I did that, the IDE automated a few additional steps for me:
The IDE prepended Local to the entity's name. This nomenclature helps me keep track of which database I'm touching: server or client. The IDE also generated similar CRUD actions to those available on the server, except these white-orange icons indicate local actions.
I fleshed out my data model by adding an Author entity and forming a relationship between Book and Author. Here's the current map:
To use the data, the IDE lets me define custom actions to retrieve the data, cache it to the local database, then read those values into local variables. Here's an example of a local action that fetches books from the central database, then caches them as local versions:
Their tool also enables developers to implement offline capabilities using an offline-sync paradigm. After time spent off the grid, the app will execute a custom local sync action when it detects the presence of an Internet connection.
Thankfully, we get to implement the syncing logic ourselves. But the approach may be as simple as refreshing the cache or as advanced as data merging with conflict resolution.
Handle Universal Layouts
As mobile developers, we have two approaches when it comes to supporting multiple screen sizes: separate apps for tablet and phone or a universal app. OutSystems handles both tactics:
In universal applications, the platform provides two client methods, isTablet() and isPhone(). These permit us to navigate the user to an interface we've optimized for their device. Here's how that logic looks in the starting template:
Neither a phone nor a tablet? Set your hair on fire.
Here's a video of that logic in action:
Continue reading %Low-Code Mobile Basics with OutSystems%
by Stanley Idesis via SitePoint
TalentAtlas
by Rob Hope via One Page Love
Digital Fonts: A Condensed History
[special]This post was previously published on the 99designs blog. Want the best designs to revamp your business? Consider launching a design contest on 99designs![/special]
More than ever before, designers today are tasked with designing with digital tools, for digital environments like web pages. The digital-to-print connection, once paramount, is now only one task among many. This change affects all aspects of design, but perhaps none more than typography, where the readability of digital fonts depends so much on the environment of display.
Or does it? As digital hardware gets better and better—we’re thinking of retina screens, etc.—the question arises of whether there is still a meaningful difference between digital fonts and any other type. What does the future have in store?
With this question in mind, we decided to set our sights toward the past and investigate the history of digital fonts. How exactly did typography change with the invention and mass adoption of computers? What can this history tell us about our own time?
The history of digital fonts turned out to be much more complex than we expected, stretching back all the way to the 1950s (at least). Here we sum it up in a version that, to borrow from typographic lingo, is significantly “condensed.”
Continue reading %Digital Fonts: A Condensed History%
by Alex Bigman via SitePoint