Permalink
Browse files

plenty of spelling fixes

  • Loading branch information...
1 parent 2740d43 commit 5b7a75901ede85902a6d450beb6b1c708f2d0c08 @xsawyerx xsawyerx committed Nov 27, 2010
@@ -1,28 +1,28 @@
-=head1 Adding authentication to your application
+=head1 Adding authentication to your application
-Web application security, arguably the most important part of any system, is a task
-(or rather a pain-point) that most developers deal with during the development of
-each new system, in an ad-hoc manner. The complexity of this task is usually
-attributed to the TIMTOWTDI (there is more than one way to do it) nature of security
-in web applications. Most developers have no real understanding of what application
+Web application security, arguably the most important part of any system, is a task
+(or rather a pain-point) that most developers deal with during the development of
+each new system, in an ad-hoc manner. The complexity of this task is usually
+attributed to the TIMTOWTDI (there is more than one way to do it) nature of security
+in web applications. Most developers have no real understanding of what application
security models exist, what models are popular, what models are recommended or why.
This means that most developers, beyond the coding of the login screen, are mainly
winging-it (making assumptions) as they go.
L<Dancer::Plugin::Auth::RBAC> takes the TIMTOWTDIBSCINABTE (there is more than one
-way to do it, but sometimes consistency isn't a bad thing either) approach towards
-web application system security by providing a standard, reusable RBAC (role-based
-access control) framework for your Dancer applications. Compared to other system
-security models (e.g. ACL, etc), Dancer::Plugin::Auth::RBAC provides flexible and
-granular access control through the use of roles, operations (tasks), and actions.
-In this article I will first explain why RBAC is the best security model choice, how
+way to do it, but sometimes consistency isn't a bad thing either) approach towards
+web application system security by providing a standard, reusable RBAC (role-based
+access control) framework for your Dancer applications. Compared to other system
+security models (e.g. ACL, etc), Dancer::Plugin::Auth::RBAC provides flexible and
+granular access control through the use of roles, operations (tasks), and actions.
+In this article I will first explain why RBAC is the best security model choice, how
RBAC works, and finally, show you a few examples on how Dancer::Plugin::Auth::RBAC
-approaches RBAC.
+approaches RBAC.
=head2 Why Role-Based Access Control
RBAC provides the most granular access control system, whereby a user may have
-multiple simultaneous permissions, which can have restrictable actions. The
+multiple simultaneous permissions, which can have restricted actions. The
following is an attempt to illustrate this:
user (the user)
@@ -33,11 +33,11 @@ following is an attempt to illustrate this:
task (which has permission to)
action (perform this action)
-Like other ACL systems (access control lists), RBAC subjects (users) can have
-multiple roles. The difference between ACL and RBAC is the added granularity of the
-permissions (tasks) and actions. Using the example above, user access can be
-validated at 4-points (the existence of the user, the role(s) of the user, the
-permission(s) of the user, and the action(s) of the user). The following is an
+Like other ACL systems (access control lists), RBAC subjects (users) can have
+multiple roles. The difference between ACL and RBAC is the added granularity of the
+permissions (tasks) and actions. Using the example above, user access can be
+validated at 4-points (the existence of the user, the role(s) of the user, the
+permission(s) of the user, and the action(s) of the user). The following is an
attempt to illustrate this:
if ($user) {
@@ -58,31 +58,31 @@ L<http://en.wikipedia.org/wiki/Rbac>.
=head2 How RBAC Works in Dancer::Plugin::Auth::RBAC
-Dancer::Plugin::Auth::RBAC seperates authentication and access control into two
+Dancer::Plugin::Auth::RBAC separates authentication and access control into two
namespaces, L<Dancer::Plugin::Auth::RBAC::Credentials>, which is responsible for
instructing Dancer::Plugin::Auth::RBAC where to find user accounts and how to
authenticate them, and L<Dancer::Plugin::Auth::RBAC::Permissions>, which specifies
the system access control roles, operations and actions.
Dancer::Plugin::Auth::RBAC ships with 4 authentication modules out-of-the-box which
-are Config.pm, MySQL.pm, SQLite.pm, and PostgreSQL.pm. Currently
-Dancer::Plugin::Auth::RBAC only ships with one access control module which is
-Dancer::Plugin::Auth::RBAC::Permissions::Config, which should be sufficient for most
+are Config.pm, MySQL.pm, SQLite.pm, and PostgreSQL.pm. Currently
+Dancer::Plugin::Auth::RBAC only ships with one access control module which is
+Dancer::Plugin::Auth::RBAC::Permissions::Config, which should be sufficient for most
use cases.
-A typical web application using Dancer::Plugin::Auth::RBAC should load the
-Dancer::Plugin::Auth::RBAC plugin and specify one authentication module and one
-access control module. Dancer::Plugin::Auth::RBAC will then provide all the neccessary
+A typical web application using Dancer::Plugin::Auth::RBAC should load the
+Dancer::Plugin::Auth::RBAC plugin and specify one authentication module and one
+access control module. Dancer::Plugin::Auth::RBAC will then provide all the necessary
functions needed to authenticate, restrict, revoke and grant access.
=head2 RBAC via Dancer::Plugin::Auth::RBAC
-Here we will demonstrate how to utilize RBAC in your web application via
-Dancer::Plugin::Auth::RBAC. First we need to decide how we will be creating and
-storing user accounts. For demonstrational purposes we will use our application
+Here we will demonstrate how to utilize RBAC in your web application via
+Dancer::Plugin::Auth::RBAC. First we need to decide how we will be creating and
+storing user accounts. For demonstration purposes we will use our application
configuration file as our datastore for user accounts etc. This means for
authentication we need to load Dancer::Plugin::Auth::RBAC::Credentials::Config and
-Dancer::Plugin::Auth::RBAC::Permissions::Config, since there is only one access
+Dancer::Plugin::Auth::RBAC::Permissions::Config, since there is only one access
control class. Our config.yml file should look as follows:
plugins:
@@ -143,97 +143,97 @@ control class. Our config.yml file should look as follows:
- view
Now that we have specified our plugin options in our application configuration
-file, we need to design our Dancer application to restrict access using the methods
+file, we need to design our Dancer application to restrict access using the methods
provided by Dancer::Plugin::Auth::RBAC. Dancer::Plugin::Auth::RBAC provides the auth()
-function to Dancer which returns a new instance of Dancer::Plugin::Auth::RBAC which
+function to Dancer which returns a new instance of Dancer::Plugin::Auth::RBAC which
provides asa(), can(), roles(), errors() and revoke().
use Dancer;
use Dancer::Plugin::Auth::RBAC;
-
+
# get new Dancer::Plugin::Auth::RBAC instance and check credentials
my $user = auth(params->{'login'}, params->{'password'});
-
+
# check if authentication passed
if ($user->errors) {
return 'failed';
}
-
+
# check if authenticated user has an admin role
if ($user->asa('admin')) {
return 'im an admin';
}
-
-Typical usuage would be to put user checking in a before filter and authentication
+
+Typical usage would be to put user checking in a before filter and authentication
login on the login page, e.g.
use Dancer;
use Dancer::Plugin::Auth::RBAC;
-
+
# check that Dancer::Plugin::Auth::RBAC
# has populated the user session info
before sub {
-
+
unless (authd) {
return redirect '/login'
unless request->path eq '/login' ;
- }
-
+ }
+
return redirect '/'
unless request->path eq '/' ;
-
+
};
-
+
any '/login' => sub {
my $user = auth(params->{'login'}, params->{'password'});
return redirect '/dashboard' unless $user->errors;
};
-Once your basic user authentication and application security is in place you can
+Once your basic user authentication and application security is in place you can
move on to doing more advanced and sophisticated role-based access control using
asa(), can(), and revoke().
use Dancer;
use Dancer::Plugin::Auth::RBAC;
-
+
# auth() will return a new Dancer::Plugin::Auth::RBAC instance using the
# authentication information stored in your session file
-
+
my $user = auth;
-
+
# check if the user has the specified role
if ($user->asa('admin')) {
return 'im an admin';
}
-
+
# check if any of the users roles can perform the specified operation
my $operation = 'manage accounts';
if ($user->can($opertion)) {
-
+
# user can manage accounts but can they ..
if ($user->can($opertion, 'create')) {
-
+
# user can manage accounts and create them :}
-
+
}
-
+
}
-
+
Even better, use RBAC in your TT (Template-Toolkit) templates as follows:
use Dancer;
use Dancer::Plugin::Auth::RBAC;
-
+
get '/dashboard' => sub {
-
+
# use Dancer::Plugin::Auth::RBAC in your templates
template 'dashboard', {
'auth' => sub { return auth(@_) }
};
};
-
+
.... in your TT template
-
+
<html>
<head>
<title>The Dashboard</title>
@@ -252,11 +252,11 @@ Even better, use RBAC in your TT (Template-Toolkit) templates as follows:
</div>
</body>
</html>
-
+
=head2 Conclusion
So you see, L<Dancer::Plugin::Auth::RBAC> provides the best access control system using
-the best web application framework with minimal effort. Let's keep web application
+the best web application framework with minimal effort. Let's keep web application
development fun! Thanks for reading.
=head2 Author
@@ -1,4 +1,4 @@
-=head1 Authentication with Tiwtter OAuth
+=head1 Authentication with Twitter OAuth
In this article we'll see how to authenticate our users via Twitter's OAuth
mechanism, using L<Dancer::Plugin::Auth::Twitter>.
@@ -143,7 +143,7 @@ So now, we can play with it, let's do a "Twitter hello world":
As our before filter will catch any unauthenticated user and redirect them to
Twitter if needed, it's that simple.
-Note that the L<Net::Twitter> object accesible via the C<twitter> keyword
+Note that the L<Net::Twitter> object accessible via the C<twitter> keyword
allows you all that the Twitter ReST API provides, so your possibilities are
endless.
@@ -82,8 +82,8 @@ github (http://github.com/$user/dancer), and you click on the B<Pull Request>
button.
You can at any time see all the commits done by others that have not yet been
-merged into one of our branches at L<this
-url|http://github.com/sukria/Dancer/forkqueue>.
+merged into one of our branches at
+L<this URL|http://github.com/sukria/Dancer/forkqueue>.
=head3 Reporting and/or fixing bugs
@@ -95,7 +95,7 @@ something like 'closes gh-xxx" where xxx is the bug id.
=head2 Community work
-There is nearly 40 differents contributors to Dancer. There is a lot of plugins
+There is nearly 40 different contributors to Dancer. There is a lot of plugins
and engines available on CPAN and github. This is a real community effort.
Thank you to everyone who have contributed so far!
@@ -1,6 +1,6 @@
-=head1 Writing ReST webservices with Dancer
+=head1 Writing ReST web services with Dancer
-It's really easy to write ReST webservices with Dancer.
+It's really easy to write ReST web services with Dancer.
A ReST application is defined by:
@@ -16,7 +16,7 @@ A ReST application is defined by:
=head2 Serializers
-Dancer comes with some helper functions, in order to help you to serialize your Perl data strcture to something like JSON or XML.
+Dancer comes with some helper functions, in order to help you to serialize your Perl data structure to something like JSON or XML.
The core provides serializers for:
@@ -61,7 +61,7 @@ As you can see, we no longer need to call the B<content_type> and B<to_json> fun
=head3 Let the user select the format.
-If you have installed the required dependancies for using all the supported serializers by Dancer (XML::Simple, YAML and JSON), you can even let the user choose in which format he prefers to have the content of the request. For this, you'll need to set the serliazer to B<mutable>. From now on, you can select your format by defining the correct value in the HTTP header of your request (Content-Type when doing a POST or PUT operation, and Accept-Type for GET and DELETE).
+If you have installed the required dependencies for using all the supported serializers by Dancer (XML::Simple, YAML and JSON), you can even let the user choose in which format he prefers to have the content of the request. For this, you'll need to set the serializer to B<mutable>. From now on, you can select your format by defining the correct value in the HTTP header of your request (Content-Type when doing a POST or PUT operation, and Accept-Type for GET and DELETE).
So, if we take our previous example, by setting the serializer to B<mutable>, we can do the following:
@@ -99,7 +99,7 @@ As we have seen, you can already define the format by setting the B<serializer>
=head3 Resources
-As stated at the begining of the article, with ReST you defined routes to access resources. So let's do this:
+As stated at the beginning of the article, with ReST you defined routes to access resources. So let's do this:
resource user =>
'get' => \&on_get_user,
@@ -13,7 +13,7 @@ structure. Then you can use DBIC to create, update, delete, search, and do many
more things on the data that are in your database.
From a Dancer web application, it is very easy to use DBIC, thanks to
-C<Dancer::Plugin::DBIC>. This article wwill implement a simple web application to
+C<Dancer::Plugin::DBIC>. This article will implement a simple web application to
demonstrate the use of C<Dancer::Plugin::DBIC>.
=head2 Simple example
@@ -70,7 +70,7 @@ template engine:
=head3 Create a view
We need a view to display the search form, and below, the results, if any. The
-results will be feeded by the route to the view as an C<arrayref> of results.
+results will be fed by the route to the view as an C<arrayref> of results.
Each result is a I<hashref>, with a C<author> key containing the name of the
author, and a C<books> key containing an I<arrayref> of strings : the books
names.
@@ -86,8 +86,8 @@ That explanation is probably hard to follow, so here is an example, much easier:
}
]
-So, what will look the view like ? Here is a simple example, displaying the
-search form, and the results, if any. IT's written in Template Toolkit, except
+So, what will look the view like? Here is a simple example, displaying the
+search form, and the results, if any. It's written in Template Toolkit, except
that Dancer changes the C<[‰ %]> format to be C<< <% %> >> instead.
# bookstore/views/search.tt
@@ -159,13 +159,14 @@ Simple stuff: we have 2 tables, one for authors, and one for books, that points
=head3 Populate with some data
Ian M. Banks
+
Richard Matheson
-Frank Herbert
+Frank Herbert
=head2 Use DBIC
-Instead of interactign with the database using SQL, let's configure
+Instead of interacting with the database using SQL, let's configure
DBIX::Class. DBIC needs to understand how your data are organized in your
database. There are two ways of letting DBIC know:
@@ -181,10 +182,10 @@ or by letting DBIC connect to the database, explore it, and generate the schema
=back
-I'll demonstrate the use of the two solutions. I'm personnaly not a big fan of
+I'll demonstrate the use of the two solutions. I'm personally not a big fan of
the detection method: on complex database, it doesn't get everything right, so
one needs to help DBIC. I prefer describing the schema manually. But hey,
-TIMTOWDI.
+TIMTOWTDI.
=head3
@@ -8,7 +8,7 @@ RSS feeds can be generated from the list of generated files and their
creation dates. If you have enough disk space, it's possible to generate
all image sizes for a picture gallery in advance. And so on.
-Having a static web site ensures maximum speed (any webserver can handle
+Having a static web site ensures maximum speed (any web server can handle
static files) and security (without forms or databases, there is little
chance for an SQL injection attack to be successful).
Oops, something went wrong.

0 comments on commit 5b7a759

Please sign in to comment.