Bump version to 0.0.9 for sprint9
Move login to a frontend backbone app

Login/authentication was being served by the sails backend
in previous revisions.  This commit moves the login functionality
to be a frontend backbone application, initiated by the navigation
app.

To enable this, needed to pass user credentials in the layout.ejs
from the backend if someone is logged in.  Then use those credentials
to render the page.  The app is initiated if login is clicked,
and then stores the user credentials for other pages to use
in the `window.cache.currentUser` variable.  Added a
`window.cache.userEvents` object to trigger new events
like user:login and user:logout.
Fix for attachments not uploading

The problem was that all attachments were being treated as
images, which would fail for non-image file types.  Remove
the image processing from the attachment app logic.

Need to add some more tests to prevent the server from failing
on bad images.  Coming soon.
Prevent malformed images from crashing server

Check the err and size variables before proceeding.

Should make it best practice to return to the error message
as well in the error object; starting that with this commit.
Restrict photo uploads to photo types

Only allow image/* or gif/jpg/png image files for
profile/project images.
Update login branch with fileupload improvements

Merge branch 'sprint9' into sprint9-login
Fix for login window not disappearing

We need to wait to do other actions until after the modal
disappears.  Add a new event, `user:login:success`, which
most apps should bind to that is what happens after
the modal successfully disappears and the page is reloaded.

Don't bind to `user:login` or `user:logout` unless there's
a good reason, instead use
`user:login:success` and `user:logout:success`
Trigger login on unauthorized page

If you reach a page where you're not logged in, or you
decided to log out on a page that you're uniquely able to
view, trigger the login dialog.  Currently implemented
for the profile page.

Trigger `user:request:login` and the login dialog will appear.

You can pass a custom message to the trigger if you'd like to
inform the user of why you're showing the dialog.  Such as:

window.cache.userEvents.trigger('user:request:login',
	'You must be logged in to view profiles.');

Added an alert template so that alerts can be rendered by
a page instead of a blank canvas.
Add more login configuration options

Now can specify whether the login fields for
username/password are expanded by default.

For deployment at State, for example, can now
disable the 'logout' function.  Since users will be
automatically logged in by their domain, don't want to
give them the option to log out.
Move frontend config files

The frontend config files were in the components directory.

Move them to the config directory, since this makes a lot more
sense.  Update documentation to match.
Merge DK's direct master changes

These should have went into a branch, but went into master.

Merge them back into the branch so the next merge with
master is easier.

Merge branch 'master' into sprint9-login
Minor bug fixes -- login > loginClick
Pass LinkedIn fields; fix callback url bug

Need to extract in a common manner the LinkedIn profile fields
that are useful for setting up a user's account.

There was also a bug where the callback would always be specified
to be localhost.  Instead, use the settings from
config/settings/auth.js which was previously not being used.
Move user creation to utils

Instead of being in auth.js, seems to make more sense
to be utility functions in api/services/utils just like
tags, projects, etc.

Fix the error objects to be consistent across the application
so that 'message' is what's displayed.
Display name or username

If name isn't set yet, display username (which
is likely the email address)
Store email (local) and providerinfo (oauth)

If logging in for the first time with a local
account, check if the username is an email address
(in most cases it will be if the front end validates
that the username is an email address).  If it is, then
add it to the list of email addresses for that user.

If adding a service and it has more info about the
person, copy over those fields to the person's profile,
such as title, bio, etc.

No support yet for copying tags (location, company,
skills, topic)
Purely comment update

Putting comments in the user workflow so it is clear
what's going on at which stage.
Minor bug in change to findOne (vs find)
Validator throws errors, not return true/false

Fix to a try/catch block instead of true/false.
Everything else basically works the same.
Add ability to enable/disable users

The user can disable themselves.
Admins can disable any user.
Only admins can re-enable a user.

Useful for disabling temporary accounts that are
used to initialize the system or for demo data.

Also will be needed when we implement an admin interface.