- Overview of Lucky
- Installing Lucky
- Configuring Your Application
- Setting Up & Migrating the Database
- Actions and Routing
- Rendering HTML Pages
- Models and Querying the Database
- Custom Queries
- Saving Data with Forms
- Asset Handling
- Tasks in Lucky
- Logging and Error Handling
- Writing JSON APIs
- Generating Test Data with Boxes
- Browser Tests with LuckyFlow
- Sending Emails with Carbon
- Deploying Lucky with Heroku
Generated file locations
By default Lucky generates files for authentication with email and password. Actions require sign in by default (set in
BrowserAction), but can be configured differently by modifying these files. You can also remove feature by removing the folders. For example if you don’t want to allow sign up (maybe users are added manually or through an API), you can remove the sign_ups actions, pages, and forms
Actions and action mixins:
src/actions/mixins/auth/*- mixins for requiring sign in, skipping sign in, etc.
src/actions/mixins/password_resets/*- mixins for working with password resets.
src/actions/browser_action.cr- this is where the authentication methods are included
src/actions/home/index.cr- handles what to do when a user hits the home page and is signed in or not
src/forms/mixins/password_validations.cr- mixin used in the
PasswordResetFormso password validations are the same in both
Pages & Layouts:
src/pages/guest_layout.cr- this layout is used by the auth pages and does not require or have access to the
Model, migration, and query:
db/migrations/00000000000001_create_users.cr- create the initial users table
Optional sign in
By default Lucky assumes most pages require sign in (apps like Gmail, SalesForce, and Dropbox). To handle this the
Auth::RequireSignIn module is included in the
Some apps have pages where guests can visit without sign in (Reddit, Twitter, ebay). If you have pages like that you’ll need to make a couple changes:
When the page looks very similar for signed out users
current_user optional in the
# From this needs current_user : User # To this needs current_user : User?
In your actions that don’t require sign in include the
class Users::Index < BrowserAction include Auth::SkipRequireSignIn # other code end
To use the
current_user in your pages you’ll now need check if it is nil or not:
def content @current_user.try do |user| text user.email end # or if you need an else branch user = @current_user if user text "Signed in as: " text user.email else text "Not signed in!" end end
When a page looks very different
When pages look very different (different columns, sections, sidebars, etc.) it is usually best to extract a new layout.
First, Duplicate the
src/pages/main_layout.crand give it a new name.
needs current_user : Userfrom the new layout if this page is only for signed out users. If the page may have a signed in user make the
needs current_user : User?
If you remove
needs current_userbecause the layout is only for signed out users then remember to include
Auth::RedirectIfSignedInin your actions so that the
current_useris not exposed to the page. If the layout is for users that may or may not be signed in then include
Auth::SkipRequireSignInin the actions that do not require sign in.