[Catalyst-commits] r8176 - in trunk:
Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx
Catalyst-Manual/lib/Catalyst/Manual/Tutorial
Catalyst-Plugin-Authentication/lib/Catalyst/Plugin
Catalyst-Plugin-Session/lib/Catalyst/Plugin
Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session
Catalyst-Plugin-Session-State-Cookie/lib/Catalyst/Plugin/Session/State
jester at dev.catalyst.perl.org
jester at dev.catalyst.perl.org
Tue Aug 5 01:32:19 BST 2008
Author: jester
Date: 2008-08-05 01:32:19 +0100 (Tue, 05 Aug 2008)
New Revision: 8176
Modified:
trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm
trunk/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/Intro.pod
trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm
trunk/Catalyst-Plugin-Session-State-Cookie/lib/Catalyst/Plugin/Session/State/Cookie.pm
trunk/Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session.pm
trunk/Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session/Tutorial.pod
Log:
typo fixing
Modified: trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm
===================================================================
--- trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm 2008-08-01 16:58:25 UTC (rev 8175)
+++ trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm 2008-08-05 00:32:19 UTC (rev 8176)
@@ -243,7 +243,7 @@
=item store_user_class
This allows you to override the authentication user class that the
-DBIx::Class store module uses to perform it's work. Most of the
+DBIx::Class store module uses to perform its work. Most of the
work done in this module is actually done by the user class,
L<Catalyst::Authentication::Store::DBIx::Class::User>, so
overriding this doesn't make much sense unless you are using your
@@ -264,7 +264,7 @@
=head2 Simple Retrieval
-The first, and most common, method is simple retrieval. As it's name implies
+The first, and most common, method is simple retrieval. As its name implies
simple retrieval allows you to simply to provide the column => value pairs
that should be used to locate the user in question. An example of this usage
is below:
@@ -285,7 +285,7 @@
syntax to retrieve the user according to whatever rules you have.
NOTE: Because the password in most cases is encrypted - it is not used
-directly but it's encryption and comparison with the value provided is usually
+directly but its encryption and comparison with the value provided is usually
handled by the Password Credential. Part of the Password Credential's behavior
is to remove the password argument from the authinfo that is passed to the
storage module. See L<Catalyst::Authentication::Credential::Password>.
@@ -321,8 +321,8 @@
modification of the authinfo hash, or to avoid overlap between credential and
store key names. It's a good idea to avoid using it in this way unless you are
sure you have an overlap/modification issue. However, the two advanced
-retrieval methods, B<searchargs> and B<resultset>, require it's use, as they
-are only processed as part of the 'dbix_class' hash
+retrieval methods, B<searchargs> and B<resultset>, require its use, as they
+are only processed as part of the 'dbix_class' hash.
=over 4
Modified: trunk/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/Intro.pod
===================================================================
--- trunk/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/Intro.pod 2008-08-01 16:58:25 UTC (rev 8175)
+++ trunk/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/Intro.pod 2008-08-05 00:32:19 UTC (rev 8176)
@@ -277,7 +277,7 @@
=head1 CATALYST INSTALLATION
-While the rough edges of catalyst installation have been a problem in
+While the rough edges of Catalyst installation have been a problem in
the past, this is now mostly solved. Nonetheless, installing Catalyst
can be a little time consuming. Although a compelling strength of
Catalyst is that it makes use of many of the modules in the vast
@@ -292,7 +292,7 @@
Ubuntu
-Given the popularity of Ubuntu and it's ease of use, Ubuntu can be
+Given the popularity of Ubuntu and its ease of use, Ubuntu can be
a great way for newcomers to experiment with Catalyst. Because it
is a "live CD," you can simply boot from the CD, run a few commands,
and you should have a fully functional environment in which to do
Modified: trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm
===================================================================
--- trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm 2008-08-01 16:58:25 UTC (rev 8175)
+++ trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm 2008-08-05 00:32:19 UTC (rev 8176)
@@ -99,7 +99,7 @@
## if we have a valid session handler - we store the
## realm in the session. If not - we have to hope that
- ## the realm can recognize it's frozen user somehow.
+ ## the realm can recognize its frozen user somehow.
if ($c->isa("Catalyst::Plugin::Session") &&
$c->config->{'Plugin::Authentication'}{'use_session'} &&
$c->session_is_valid) {
@@ -238,7 +238,7 @@
}
# old default was to force use_session on. This must remain for that
- # reason - but if use_session is already in the config, we respect it's setting.
+ # reason - but if use_session is already in the config, we respect its setting.
if (!exists($cfg->{'use_session'})) {
$cfg->{'use_session'} = 1;
}
@@ -270,7 +270,7 @@
}
}
- ## if the default realm did not have a defined priority in it's config - we put it at the front.
+ ## if the default realm did not have a defined priority in its config - we put it at the front.
if (!exists($cfg->{'realms'}{$defaultrealm}{'user_restore_priority'})) {
$auth_restore_order{'default'} = 1;
}
Modified: trunk/Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session/Tutorial.pod
===================================================================
--- trunk/Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session/Tutorial.pod 2008-08-01 16:58:25 UTC (rev 8175)
+++ trunk/Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session/Tutorial.pod 2008-08-05 00:32:19 UTC (rev 8176)
@@ -6,23 +6,23 @@
=head1 ASSUMPTIONS
-This tutorial assumes that you are familiar with web applications in general
-and Catalyst specifically (up to models and configuration), that you know what
-HTTP is.
+This tutorial assumes that you are familiar with web applications in
+general and Catalyst specifically (up to models and configuration), and
+that you know what HTTP is.
=head1 WHAT ARE SESSIONS
When users use a site, especially one that knows who they are (sites you log in
-to, sites which let you keep a shopping cart, etc), the server preparing the
+to, sites which let you keep a shopping cart, etc.), the server preparing the
content has to know that request X comes from client A while request Y comes
-from client B, so that each user gets the content most appropriate for it.
+from client B, so that each user gets the content meant for it.
The problem is that HTTP is a stateless protocol. This means that every request
is distinct, and even if it comes from the same client, it's difficult to know
that.
The way sessions are maintained between distinct requests is that the client
-says, for every request "I'm client A" or "I'm client B".
+says, for every request, "I'm client A" or "I'm client B".
This piece of data that tells the server "I'm X" is called the session ID, and
the threading of several requests together is called a session.
@@ -36,8 +36,8 @@
request is made.
The way they work is that the server sends the C<Set-Cookie> header, with a
-cookie name, a value, and some meta data (like when it expires, what paths it
-applies to, etc). The client saves this.
+cookie name, a value, and some metadata (like when it expires, what paths it
+applies to, etc.). The client saves this.
Then, on every subsequent request the client will send a C<Cookie> header, with
the cookie name and value.
@@ -52,9 +52,9 @@
This technique has several issues which are discussed in
L<Catalyst::Plugin::Session::State::URI/CAVEATS>.
-=head2 Server-side Behavior
+=head2 Server-Side Behavior
-When the server receives the session ID it can then look this key up into a
+When the server receives the session ID it can then look this key up in a
database of some sort. For example the database can contain a shopping cart's
contents, user preferences, etc.
@@ -101,13 +101,13 @@
After the plugins are loaded they need to be configured. This is done according
to L<Catalyst::Manual::Cookbook/Configure_your_application>.
-Each backend plugin requires it's own configuration options (with most plugins
+Each backend plugin requires its own configuration options (with most plugins
providing sensible defaults). The session API itself also has configurable
options listed in L<Catalyst::Plugin::Session/CONFIGURATION>.
For the plugins above we don't need any configuration at all - they should work
-out of the box, but suppose we did want to change some things arond, it'll look
-like this:
+out of the box, but suppose we did want to change some things around, it'll
+look like this:
MyApp->config( session => {
cookie_name => "my_fabulous_cookie",
@@ -150,19 +150,19 @@
if appropriate, at the start of the request (e.g. by looking at the cookies
sent by the client).
-If a session ID is set then the store will be asked to retrieve the session
+If a session ID is set, the store will be asked to retrieve the session
data for that specific session ID, and this is returned from
C<< $c->session >>. This retrieval is cached, and will only happen once per
request, if at all.
-If a session ID is not set, then one is generated, a new anonymous hash is
+If a session ID is not set, a new one is generated, a new anonymous hash is
created and saved in the store with the session ID as the key, and the
reference to the hash is returned.
The action above takes this hash reference, and updates a nested hash within
it, that counts quantity of each item as stored in the cart.
-Any cart listing code can then look into the session data and use it to display
+Any cart-listing code can then look into the session data and use it to display
the correct items, which will, of course, be remembered across requests.
Here is an action some Template Toolkit example code that could be used to
@@ -202,7 +202,7 @@
[%# the table body lists all the items in the cart %]
[% FOREACH item_id = cart.items.keys %]
- [%# each item has it's own row in the table %]
+ [%# each item has its own row in the table %]
[% item = cart.items.$item_id %]
[% quantity = cart.quantity.$item_id %]
@@ -259,7 +259,7 @@
=head2 (Not) Trusting the Client
-In order to avoid the overhead of serverside data storage, the session data can
+In order to avoid the overhead of server-side data storage, the session data can
be included in the cookie itself.
There are two problems with this:
@@ -303,7 +303,7 @@
they can use this to put JavaScript code on the server.
If the server does not enforce a strict subset of tags that may be used, the
-malicious user could use this code to steal the cookies (there is a javascript
+malicious user could use this code to steal the cookies (there is a JavaScript
API that lets cookies be accessed, but this code has to be run on the same
website that the cookie came from).
Modified: trunk/Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session.pm
===================================================================
--- trunk/Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session.pm 2008-08-01 16:58:25 UTC (rev 8175)
+++ trunk/Catalyst-Plugin-Session/lib/Catalyst/Plugin/Session.pm 2008-08-05 00:32:19 UTC (rev 8176)
@@ -745,9 +745,9 @@
=item prepare_action
-This methoid is extended.
+This method is extended.
-It's only effect is if the (off by default) C<flash_to_stash> configuration
+Its only effect is if the (off by default) C<flash_to_stash> configuration
parameter is on - then it will copy the contents of the flash to the stash at
prepare time.
@@ -768,7 +768,7 @@
=item create_session_id
-Creates a new session id using C<generate_session_id> if there is no session ID
+Creates a new session ID using C<generate_session_id> if there is no session ID
yet.
=item validate_session_id SID
@@ -783,7 +783,7 @@
This method will return a string that can be used as a session ID. It is
supposed to be a reasonably random string with enough bits to prevent
collision. It basically takes C<session_hash_seed> and hashes it using SHA-1,
-MD5 or SHA-256, depending on the availibility of these modules.
+MD5 or SHA-256, depending on the availability of these modules.
=item session_hash_seed
@@ -806,7 +806,7 @@
=back
-In the hopes that those combined values are entropic enough for most uses. If
+in the hopes that those combined values are entropic enough for most uses. If
this is not the case you can replace C<session_hash_seed> with e.g.
sub session_hash_seed {
@@ -951,13 +951,13 @@
To let these users access your site you can either disable address verification
as a whole, or provide a checkbox in the login dialog that tells the server
that it's OK for the address of the client to change. When the server sees that
-this box is checked it should delete the C<__address> sepcial key from the
+this box is checked it should delete the C<__address> special key from the
session hash when the hash is first created.
=head2 Race Conditions
-In this day and age where cleaning detergents and dutch football (not the
-american kind) teams roam the plains in great numbers, requests may happen
+In this day and age where cleaning detergents and Dutch football (not the
+American kind) teams roam the plains in great numbers, requests may happen
simultaneously. This means that there is some risk of session data being
overwritten, like this:
@@ -965,7 +965,7 @@
=item 1.
-request a starts, request b starts, with the same session id
+request a starts, request b starts, with the same session ID
=item 2.
@@ -990,7 +990,7 @@
=back
-If this is a concern in your application, a soon to be developed locking
+If this is a concern in your application, a soon-to-be-developed locking
solution is the only safe way to go. This will have a bigger overhead.
For applications where any given user is only making one request at a time this
Modified: trunk/Catalyst-Plugin-Session-State-Cookie/lib/Catalyst/Plugin/Session/State/Cookie.pm
===================================================================
--- trunk/Catalyst-Plugin-Session-State-Cookie/lib/Catalyst/Plugin/Session/State/Cookie.pm 2008-08-01 16:58:25 UTC (rev 8175)
+++ trunk/Catalyst-Plugin-Session-State-Cookie/lib/Catalyst/Plugin/Session/State/Cookie.pm 2008-08-05 00:32:19 UTC (rev 8176)
@@ -193,12 +193,12 @@
=item finalize_cookies
-Will set a cookie called C<session> if it doesn't exist or if it's value is not
+Will set a cookie called C<session> if it doesn't exist or if its value is not
the current session id.
=item setup_session
-Will set the C<cookie_name> parameter to it's default value if it isn't set.
+Will set the C<cookie_name> parameter to its default value if it isn't set.
=back
More information about the Catalyst-commits
mailing list