Dancer2

 view release on metacpan or  search on metacpan

Releasing-Dancer2.md  view on Meta::CPAN

- Commit `Dancer2.pm` and the new `README` file to the repo (after
  which, you need to `git push`)

After this, you must `git push` to push the updated release files to
GitHub.

The test suite *must* pass before a release can be done. This is your
last chance to resolve any test failures.

Provided the tests pass, you will be prompted to continue the release
process. Provided you have your PAUSE credentials set up, this will
upload the new dist to PAUSE. If you don't have a credential file set
up, you can manually update the new release via the PAUSE web interface.

### Send out release announcements

Historically, release announcements have been sent out via the following
channels:

- dancer-users mailing list
- Twitter/X

lib/Dancer2/Config.pod  view on Meta::CPAN

Dancer2 will first look for the file F<config.EXT> (where F<EXT> is the
type of configuration file you are using; e.g. F<ini> or F<json> or
F<yml>) in the root directory of your application. This is considered
your global Dancer2 config file. If you do not care to have separate
settings for production and development environments (B<not> a
recommended practice!), then this file is all you need.

Next, Dancer2 will look for a file called F<config_local.EXT>. This file
is typically useful for deployment-specific configuration that should
not be checked into source control. For instance, database credentials
could be stored in this file.  Any settings in this file are merged into
the existing configuration such that those with the same name in your
local configuration file will take precedence over those settings in
the global file.

Next, Dancer2 will look in the F<environments> directory for a configuration
file specific to the platform you are deploying to (F<production.EXT> or
F<development.EXT>, for example).  Again, the configuration from the environment
is merged with the existing configuration with the deployment config taking
precedence.

lib/Dancer2/Cookbook.pod  view on Meta::CPAN

B<Starting the application>:
Our bookstore lookup application can now be started using the built-in server:

    # start the web application
    plackup bin/app.psgi

=back

=head2 Authentication

Writing a form for authentication is simple: we check the user credentials
on a request and decide whether to continue or redirect them to a form.
The form allows them to submit their username and password and we save that
and create a session for them so when they now try the original request,
we recognize them and allow them in.

=head3 Basic Application

The application is fairly simple. We have a route that needs authentication,
we have a route for showing the login page, and we have a route for posting
login information and creating a session.

lib/Dancer2/Manual/Deployment.pod  view on Meta::CPAN

        acl is-haproxy-stats  path_beg /stats
        # uncomment if you'd like to get haproxy usage statistics
        # use_backend haproxy   if is-haproxy-stats
        default_backend       dynamic

    # haproxy statistics (available at http://app.example.com/stats)
    backend haproxy
        stats uri             /stats
        stats refresh         180s
        stats realm           app.example.com\ haproxy\ statistics
        # change credentials
        stats auth            admin1:password1
        stats auth            admin2:password2
        stats hide-version
        stats show-legends

    # application backends
    backend dynamic
        # change path_info to check and value of the Host header sent to application server
        option httpchk HEAD / HTTP/1.1\r\nHost:\ app.example.com
        server app1 app-be1.example.com:3000 check inter 30s