view release on metacpan or  search on metacpan

lib/Crypt/XkcdPassword/Words/EN.pm  view on Meta::CPAN

elegant
elbow
customs
cuban
credibility
credentials
consistent
collapse
cloth
claws
cinderella

 view release on metacpan or  search on metacpan

lib/Crypto/Utils/OPAQUE.pm  view on Meta::CPAN

our $VERSION = 0.012;

our @ISA    = qw(Exporter);
our @EXPORT = qw/
  create_cleartext_credentials
  store
  recover
  create_registration_request
  create_registration_response
  finalize_registration_request
  derive_random_pwd
  create_credential_request
  create_credential_response
  recover_credentials
  /;

our @EXPORT_OK = @EXPORT;

sub recover_credentials {

    my (
        $cred_request,    $cred_response,       $pwd,
        $c_id,            $s_id,                $Nseed,
        $group_name,      $info,                $DST,

lib/Crypto/Utils/OPAQUE.pm  view on Meta::CPAN

    ### recover s_pub: unpack("H*", $s_pub)
    ### recover c_priv:  BN_bn2hex($recover_r->{c_priv})
    ### recover export_key: unpack("H*", $recover_r->{export_key})

    return $recover_r;
} ## end sub recover_credentials

sub create_credential_response {
    my (
        $request,               $s_pub,               $oprf_seed,
        $credential_identifier, $DSI,                 $envelope,

lib/Crypto/Utils/OPAQUE.pm  view on Meta::CPAN

    my $blindedElement_hex = sn_point2hex( $group_name, $blindedElement, 2 );
    my $request            = { data => pack( "H*", $blindedElement_hex ) };
    return { request => $request, blind => $blind, ec_params => $ec_params };
}

sub create_cleartext_credentials {
    my ( $s_pub, $c_pub, $s_id, $c_id ) = @_;

    $s_id //= $s_pub;
    $c_id //= $c_pub;

    my $cleartext_credentials =
      join( "", $s_pub, map { i2osp( length($_), 2 ) . $_ } ( $s_id, $c_id ) );

    return $cleartext_credentials;
}

sub store {
    my (
        $randomized_pwd, $s_pub,     $s_id,                $c_id,

lib/Crypto/Utils/OPAQUE.pm  view on Meta::CPAN

    my $c_priv = $c_ec_key_r->{priv_bn};
    my $c_pub  = $c_ec_key_r->{pub_bin};
    ### c_priv: BN_bn2hex($c_priv)
    ### c_pub: unpack("H*", $c_pub)

    my $cleartext_credentials =
      create_cleartext_credentials( $s_pub, $c_pub, $s_id, $c_id );
    ### cleartext_credentails: unpack("H*", $cleartext_credentials)

    my $auth_tag =
      $mac_func->( $envelope_nonce . $cleartext_credentials, $auth_key );

    my $envelope = { auth_tag => $auth_tag, nonce => $envelope_nonce };

    return {
        envelope              => $envelope,
        c_pub                 => $c_pub,
        masking_key           => $masking_key,
        export_key            => $export_key,
        c_priv                => $c_priv,
        auth_key              => $auth_key,
        cleartext_credentails => $cleartext_credentials,
    };
} ## end sub store

sub recover {
    my (

lib/Crypto/Utils/OPAQUE.pm  view on Meta::CPAN

        $expand_message_func );
    my $c_priv = $c_ec_key_r->{priv_bn};
    my $c_pub  = $c_ec_key_r->{pub_bin};
    ### c_priv: BN_bn2hex($c_priv)

    my $cleartext_credentials =
      create_cleartext_credentials( $s_pub, $c_pub, $s_id, $c_id );
    my $expected_tag =
      $mac_func->( $envelope->{nonce} . $cleartext_credentials, $auth_key );

    if ( $envelope->{auth_tag} ne $expected_tag ) {
        croak "not match envelope.auth_tag";
    }

lib/Crypto/Utils/OPAQUE.pm  view on Meta::CPAN

L<https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/>

=head1 FUNCTION

=head2 create_cleartext_credentials
 
 my $cleartext_credentials = create_cleartext_credentials($s_pub, $c_pub, $s_id, $c_id);

=head2 store

 my $store_r = store($randomized_pwd, $s_pub, $s_id, $c_id, $Nn, $Nseed, $group_name, $info, $DST, $hash_name, $expand_message_func, $mac_func);

lib/Crypto/Utils/OPAQUE.pm  view on Meta::CPAN

=head2 create_credential_response

   my $cred_res_r = create_credential_response($request, $s_pub, $oprf_seed, $credential_identifier, $DSI, $envelope, $masking_key, $Nn, $Nseed, $group_name, $info, $DST, $hash_name, $expand_message_func, $point_compress_t, $pack_func);

=head2 recover_credentials

    my $recover_r = recover_credentials($cred_request, $cred_response, $pwd, $c_id, $s_id, $Nseed, $group_name, $info, $DST, $hash_name, $expand_message_func, $mac_func, $pwd_harden_func, $unpack_func);

=cut

 view release on metacpan or  search on metacpan

lib/Curio/Role/GitLab/API/v4.pm  view on Meta::CPAN

        );
    }

The C<myapp_secret> call is expected to be the place where you use
whatever tool you use to hold your GitLab tokens and likely all
passwords and other credentials (secrets) that your application needs.

Some common tools that people use to manage their secrets are
Kubernetes' secrets objects, AWS's Secret Manager, HashiCorp's Vault,
or just an inescure configuration file; to name a few.

 view release on metacpan or  search on metacpan

Ent.pm  view on Meta::CPAN

Parameters are all passed as a hash or hash reference whose keys are described below:

I<Connection Parameters>

To establish a connection to a datastore, the caller must pass credentials.  These may be passed either in URL syntax and/or as separate keys.  Any information passed separately overrides the appropriate value in the URL.  If no connection informatio...

=over

=item DBED

 view release on metacpan or  search on metacpan

t/TestFirebird.pm  view on Meta::CPAN

    my $class = shift;
    my $self = bless {@_}, $class;

    $self->read_cached_configs;

    $self->check_credentials;

    return $self;
}

sub check_credentials {
    my $self = shift;

    unless ( defined $self->{pass}
        or defined $ENV{DBI_PASS}
        or defined $ENV{ISC_PASSWORD} )

 view release on metacpan or  search on metacpan

lib/DBD/MVS_FTPSQL.pm  view on Meta::CPAN

  my $dbh = DBI->connect("dbi:MVS_FTPSQL:$DSN", $username, $password)
            or die $DBI::errstr;  

establishes a connection to the DB2 subsystem identified by the DSN string 
C<$DSN>, using as login credentials the C<$username> and C<$password> supplied. 
Notice that in the OS/390 or z/OS environment you don't connect to a 
database, instead you have to connect to the DB2 subsystem which gives 
access to all the databases it contains (a mainframe database has very 
little to do with its pc counterpart as it is basically a logical grouping 
of tables, other objects and so, in many ways, it's more similar to a pc 

 view release on metacpan or  search on metacpan

dbdimp.c  view on Meta::CPAN

        mariadb_dr_do_error(dbh, CR_SERVER_GONE_ERROR, "MySQL server has gone away", "HY000");
        return 0;
      }
      mysql_options(imp_dbh->pmysql, FABRIC_OPT_MODE, str);
    }
    else if (memEQs(key, kl, "mariadb_fabric_opt_group_credentials"))
    {
      mariadb_dr_do_error(dbh, CR_UNKNOWN_ERROR, "'fabric_opt_group_credentials' is not supported", "HY000");
      return 0;
    }
  #endif
    else if (memEQs(key, kl, "mariadb_max_allowed_packet"))
    {

 view release on metacpan or  search on metacpan

t/lib/Neo4p/Test.pm  view on Meta::CPAN

  my $class = shift;
  my ($db,$user,$pass) = @_;
  REST::Neo4p->set_handle(0);
  unless (REST::Neo4p->connected) {
    eval {
      REST::Neo4p->agent->credentials($db,'',$user,$pass) if defined $user;
      REST::Neo4p->connect($db);
    };
    if (my $e = REST::Neo4p::CommException->caught) {
      return
    }

 view release on metacpan or  search on metacpan

lib/DBD/Oracle.pm  view on Meta::CPAN

DBMS_OUTPUT.GET is discarded by the next call to DBMS_OUTPUT.PUT_LINE,
DBMS_OUTPUT.PUT, or DBMS_OUTPUT.NEW_LINE.

=head2 B<reauthenticate ( $username, $password )>

Starts a new session against the current database using the credentials
supplied. Note that this does not work with DRCP.

=head2 B<private_attribute_info>

  $hashref = $dbh->private_attribute_info();

 view release on metacpan or  search on metacpan

sqlite3.c  view on Meta::CPAN

}

#if SQLITE_USER_AUTHENTICATION
/*
** Return TRUE if zTable is the name of the system table that stores the
** list of users and their access credentials.
*/
SQLITE_PRIVATE int sqlite3UserAuthTable(const char *zTable){
  return sqlite3_stricmp(zTable, "sqlite_user")==0;
}
#endif

 view release on metacpan or  search on metacpan

sqlite3.c  view on Meta::CPAN

}

#if SQLITE_USER_AUTHENTICATION
/*
** Return TRUE if zTable is the name of the system table that stores the
** list of users and their access credentials.
*/
SQLITE_PRIVATE int sqlite3UserAuthTable(const char *zTable){
  return sqlite3_stricmp(zTable, "sqlite_user")==0;
}
#endif

 view release on metacpan or  search on metacpan

lib/DBD/WMI.pm  view on Meta::CPAN

=over 4

=item * Implement placeholders and proper interpolation of values

=item * Need to implement DSN parameters for remote computers, credentials

=back

=head1 SEE ALSO

 view release on metacpan or  search on metacpan

xt/03_turso_live.t  view on Meta::CPAN

        "Get the correct URL from your Turso dashboard at https://app.turso.io\n";
}

plan tests => 8;

# Test 1: Connection with Turso credentials (using DBI standard password parameter)
my $dsn = "dbi:libsql:$hostname";
my $dbh = DBI->connect($dsn, '', $turso_token, {
    RaiseError => 1,
    AutoCommit => 1,
});

 view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

perl Makefile.PL
make
make test
```

See the output of `perl Makefile.PL` for how to set database credentials.

Testing is also done via GitHub action.

## Installation

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

1.000005    2012-10-08
            - Fixed: filtered column handling

1.000004    2012-09-26
            - Fixed: credentials are now transfered to commit (Steffen Schwigon)
            - Show life signal only on -vv (Steffen Schwigon)
            - Skip views for transfer (Bug #3, reported by Steffen Schwigon)

1.000003    2012-09-17
            - set user in portable way

 view release on metacpan or  search on metacpan

lib/DBIO/DuckDB.pm  view on Meta::CPAN

C<storage_type>.

=head1 TESTING

Tests use in-memory DuckDB databases and do not require external
credentials. The C<t/> directory contains user-level smoke scripts
(not automated TAP tests) for manually verifying the driver end-to-end
against a real libduckdb install.

=head1 AUTHOR

 view release on metacpan or  search on metacpan

docs/adr/0009-database-level-ddl-via-native-api.md  view on Meta::CPAN

deploy/upgrade/install path was inert until this was fixed.

Server-side co-location is the simplest placement that is guaranteed reachable:
the live DSN already names a server and a directory that the server can write
(it holds the live DB there), so the scratch DB beside it inherits the same
reachability and credentials without any extra configuration. Deriving the path
from the live DSN rather than a fixed temp dir keeps the strategy working for
both local and remote (`host/port:`) servers with no per-deployment tuning.

## Consequences

 view release on metacpan or  search on metacpan

docs/adr/0006-accessbroker-conninfo-provider-credential-rotation.md  view on Meta::CPAN

# ADR 0006 — AccessBroker credential rotation via a `_conninfo_provider` coderef

- Status: accepted
- Date: 2026-06-21
- Tags: async, accessbroker, credentials, rotation, pool, drivers

## Context

Core ADR 0013 establishes the AccessBroker / CredentialSource seam: a storage can
be handed a broker instead of raw connect info, and the broker yields credentials
on demand — the mechanism for rotating credentials (short-lived DB passwords from a
vault) without restarting the app. Core ADR 0014 notes that the *async* drivers
consume this seam at the driver level (`set_access_broker` /
`current_access_broker_connect_info`) even though it is not yet lifted into the
abstract `DBIO::Storage::Async`. The broker interface itself and the
lift-into-core question are core-owned and tracked there; this ADR does not restate
them.

The async-specific problem the seam does not solve by itself: a sync DBI storage
holds one `$dbh` and can simply re-fetch credentials the next time it
reconnects. This driver holds a **pool** of EV::MariaDB connections created lazily
and on demand by `DBIO::Storage::PoolBase`. For rotation to work, *each new pooled
connection* must be built from freshly-fetched, freshly-normalized broker
credentials — not from a single snapshot captured when the schema first connected,
which would pin the pool to a password that later expires.

## Decision

When the connect info is a single blessed `DBIO::AccessBroker`, wire the broker to
the storage and install a `_conninfo_provider` coderef that re-fetches and
re-normalizes credentials from the broker; hand that coderef to the pool so
`PoolBase` calls it to build *every* connection, instead of handing the pool a
static conninfo snapshot.

- **Detect and attach.** `connect_info` recognises the single-blessed-broker shape
  and calls `set_access_broker($broker, 'write')` (`Storage.pm:77-79`).

docs/adr/0006-accessbroker-conninfo-provider-credential-rotation.md  view on Meta::CPAN

- **Pool consumes the provider, not a snapshot.** When building the pool, if a
  `_conninfo_provider` is present it is passed as the pool's `conninfo_provider`
  (`Storage.pm:152-153`); only in the non-broker case is a static `conninfo` passed
  (`Storage.pm:155-157`). `PoolBase` then invokes the provider for each
  `_create_connection`, so every new pooled connection uses freshly-fetched
  credentials.
- **Normalize once, at the seam.** Both the provider and the non-broker path route
  through `_normalize_async_connect_info` (`Storage.pm:115-132`), which maps
  `dbname`→`database` and extracts `pool_size`; `_conninfo_hash` then treats stored
  conninfo as already-normalized and returns it as-is (`Storage.pm:168-177`) — no
  re-normalization on the hot path.

## Rationale

Rotating credentials only help if the pool actually picks them up; a pool that
captured the broker's first answer and reused it forever would authenticate new
connections with a stale password and fail once the credential expired. Passing the
pool a *provider coderef* rather than a *value* is what makes the pool's own lazy,
on-demand connection creation (ADR 0003 / core ADR 0014's PoolBase) re-pull
credentials at exactly the right moment — connection-creation time — without the
pool needing any broker knowledge or a teardown/rebuild cycle. The provider closes
over `current_access_broker_connect_info` (the core ADR 0013 hook, available because
it lives on base `DBIO::Storage`), so the driver consumes the core seam without
re-implementing credential fetching. Centralising the `dbname`→`database` /
`pool_size` normalization in one method, called by both the provider and the static

docs/adr/0006-accessbroker-conninfo-provider-credential-rotation.md  view on Meta::CPAN

without a live DB; `t/11-access-broker-live.t` against a real server), hence
**accepted**, not proposed.

## Consequences

- Broker-backed pools rotate credentials transparently: each new pooled connection
  is built from freshly-fetched, freshly-normalized broker credentials, with no
  pool teardown. Existing live connections are unaffected until they are recycled.
- The pool is handed a *coderef* in the broker case and a *value* in the non-broker
  case (`Storage.pm:152-157`). The pool's connection creation must keep calling the
  provider per connection (PoolBase contract); a change there that cached the first
  result would silently defeat rotation.

 view release on metacpan or  search on metacpan

t/10-oracle.t  view on Meta::CPAN

  'insert returning capability guessed correctly'
);

isa_ok (DBIO::Test::Schema->connect($dsn, $user, $pass)->storage->sql_maker, 'DBIO::Oracle::SQLMaker');

# see if determining a driver with bad credentials throws propely
# (sql_maker is lazy and never connects -- ensure_connected forces the connect)
throws_ok {
  DBIO::Test::Schema->connect($dsn, "BORKED BORKED USER $user", $pass)->storage->ensure_connected;
} qr/DBI Connection failed/;

 view release on metacpan or  search on metacpan

lib/DBIO/SQLite.pm  view on Meta::CPAN

SQLite DSNs and load the new storage class via the driver registry.

=head1 TESTING

SQLite tests in this distribution use in-memory databases and do not require
database credentials.

Offline SQLMaker tests can use L<DBIO::SQLite::Test> or L<DBIO::Test> with:

  storage_type => 'DBIO::SQLite::Storage'

 view release on metacpan or  search on metacpan

lib/DBIO/AccessBroker.pm  view on Meta::CPAN

use Carp qw(croak);
use Scalar::Util qw(blessed);
use namespace::clean;

# A CredentialSource: supplies connect info for exactly one backend identity.
# It provides credentials — it does NOT route. Read/write routing and the
# host topology belong to DBIO::Replicated, never here.
#
# Storage-agnostic: works with both Storage::DBI and Storage::Async. The
# primary interface is connect_info_for_storage($storage), which returns
# storage-native connection parameters. Legacy connect_info_for() remains
# available for DBI-shaped broker subclasses.
#
# Subclasses must implement:
#   connect_info_for_storage($storage) — returns storage-native connect info
#   connect_info_for()      — legacy DBI-shaped connect info
#   needs_refresh()         — returns true if credentials need rotation
#   refresh()               — perform credential rotation
#
# The $mode argument ('read'/'write') is vestigial: under a single-identity
# CredentialSource there is nothing to route on. It is accepted for
# backward compatibility and ignored by all built-in brokers.

lib/DBIO/AccessBroker.pm  view on Meta::CPAN

  # Subclasses with storage-native formats override this.
  # Default: delegate to connect_info_for (DBI-shaped).
  return $self->connect_info_for($mode);
}

# Do credentials need rotation?
sub needs_refresh { 0 }

# Perform credential rotation
sub refresh { }

# Does this broker rotate credentials over time?
sub has_rotating_credentials { 0 }

# Can transactions safely run through this broker without an explicit override?
# A broker only supplies credentials, so the sole safety hazard is credential
# rotation mid-transaction. Routing is not a broker concern (see Replicated).
sub is_transaction_safe {
  my $self = shift;
  return $self->has_rotating_credentials ? 0 : 1;
}

# Check refresh and return connect info — legacy convenience for DBI-shaped
# callers or brokers already attached to a storage.
sub current_connect_info_for {

lib/DBIO/AccessBroker.pm  view on Meta::CPAN

    ? $self->connect_info_for_storage($self->_storage, $mode)
    : $self->connect_info_for($mode);
}

# Pair this single credential identity with one host, returning a HostBound
# view. The view shares this broker's credentials and rotation lifecycle but
# reports the given host in its connect info, so one credential can serve many
# servers without this broker ever knowing the host list. Accepts a plain host
# string or a hashref ({ host => ..., port => ... }).
sub for_host {
  my ($self, @args) = @_;

lib/DBIO/AccessBroker.pm  view on Meta::CPAN

        username => 'app', password => 'secret',
    );
    # Storage gets storage-native connect info
    my $info = $broker->current_connect_info_for_storage($schema->storage);

    # Vault — rotating credentials from OpenBao/Vault
    use DBIO::AccessBroker::Vault;
    my $broker = DBIO::AccessBroker::Vault->new(
        vault     => WWW::OpenBao->new(endpoint => 'http://vault:8200', token => $token),
        dsn       => 'dbi:Pg:dbname=myapp;host=db',
        cred_path => 'database/creds/myapp',
        ttl       => 3600,         # credentials valid for 1 hour
        refresh_margin => 900,     # refresh 15 min before expiry
    );
    # DBIO can now connect directly with a broker
    my $schema = MyApp::Schema->connect($broker);

See F<t/access_broker/> for a runnable example.

=head1 DESCRIPTION

AccessBroker is a B<CredentialSource>: it supplies the connect info for
exactly one backend identity (one set of credentials). It is
B<storage-agnostic> — it returns connection parameters, not handles —
so it works with both C<Storage::DBI> (sync) and C<Storage::Async>
(async/Future-based). It handles:

=over 4

=item * B<Credential lifecycle> — fetching, rotating, and caching database credentials

=back

A broker does B<not> route, and it does B<not> own a host list. Read/write
routing and the master/replicant topology belong to L<DBIO::Replicated>. One

lib/DBIO/AccessBroker.pm  view on Meta::CPAN

DBIO::AccessBroker - Credential lifecycle for DBIO connections

=head1 TRANSACTION SAFETY

A broker only supplies credentials, so the sole hazard to a running
transaction is credentials rotating mid-flight. DBIO distinguishes:

=over 4

=item * C<has_rotating_credentials()> — new connections may need refreshed credentials

=item * C<is_transaction_safe()> — DBIO may start a transaction through this broker without an explicit override

=back

The default implementation treats brokers as transaction-safe unless they
rotate credentials.

This means:

=over 4

lib/DBIO/AccessBroker.pm  view on Meta::CPAN

=item C<connect_info_for_storage($storage)> — Return storage-native connect info

=item C<connect_info_for()> — Optional legacy DBI-shaped connect info

=item C<needs_refresh()> — Return true if credentials should be rotated

=item C<refresh()> — Perform credential rotation

=item C<has_rotating_credentials()> — Return true if credentials rotate across connections

=item C<is_transaction_safe()> — Return true if DBIO may open transactions through this broker

=back

 view release on metacpan or  search on metacpan

lib/DBIx/Class/FilterColumn/Encrypt.pm  view on Meta::CPAN

 # in application code
 $rs->create({ data => 'some secret' });

=head1 DESCRIPTION

This components transparently encrypts any value with the currently active key, or decrypts them with any known value. This is useful when needing read/write access to values that are too sensitive to store in plaintext, such as credentials for other...

To enable encryption, C<encrypt> must be a hash containing the key C<keys>, which shall be a hash mapping numberic identifiers to keys. An optional argument C<active_key> may be given which one will be used for encrypting, otherwise the key with the ...

=head1 AUTHOR

 view release on metacpan or  search on metacpan

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

        return $class->next::method( @info );
    }

    my $attrs = $class->_make_connect_attrs(@info);

    # We will not load credentials for someone who uses dbh_maker,
    # however we will pass their request through.
    return $class->next::method( $attrs )
        if defined $attrs->{dbh_maker};

    # Take responsibility for passing through normal-looking
    # credentials.
    $attrs = $class->load_credentials($attrs)
        unless $attrs->{dsn} =~ /^dbi:/i;

    return $class->next::method( $attrs );
}

sub coerce_credentials_from_mojolike {
    my ( $class, $attrs ) = @_;

    (my $in = $attrs->{dsn}) =~ s/^postgresql/http/;
    my $url = URI->new( $in );

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

}


sub _load_config {
    my ( $class ) = @_;
    require Config::Any; # Only loaded if we need to load credentials.

    # If we have ->config_files, we'll use those and load_files
    # instead of the default load_stems.
    my %cf_opts = ( use_ext => 1 );
    return @{$class->config_files}
        ? Config::Any->load_files({ files => $class->config_files, %cf_opts })
        : Config::Any->load_stems({ stems => $class->config_paths, %cf_opts });
}


sub load_credentials {
    my ( $class, $connect_args ) = @_;

    # Handle mojo-like postgres:// urls
    return $class->coerce_credentials_from_mojolike($connect_args)
        if $connect_args->{dsn} =~ /^postgresql:/i;

    # While ->connect is responsible for returning normal-looking
    # credential information, we do it here as well so that it can be
    # independently unit tested.
    return $connect_args if $connect_args->{dsn} =~ /^dbi:/i;

    return $class->filter_loaded_credentials(
        $class->_find_credentials( $connect_args, $class->config ),
        $connect_args
    );

}

# This will look through the data structure returned by Config::Any
# and return the first instance of the database credentials it can
# find.
sub _find_credentials {
    my ( $class, $connect_args, $ConfigAny ) = @_;

    for my $cfile ( @$ConfigAny ) {
        for my $filename ( keys %$cfile ) {
            for my $database ( keys %{$cfile->{$filename}} ) {

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

# Intended to be sub-classed, the default behavior is to
# overwrite the loaded configuration with any specified
# configuration from the connect() call, with the exception
# of the DSN itself.

sub filter_loaded_credentials {
    my ( $class, $new, $old ) = @_;

    local $old->{password}, delete $old->{password} unless $old->{password};
    local $old->{user},     delete $old->{user}     unless $old->{user};
    local $old->{dsn},      delete $old->{dsn};

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

DBIx::Class::Schema::Config - Credential Management for DBIx::Class

=head1 DESCRIPTION

DBIx::Class::Schema::Config is a subclass of DBIx::Class::Schema that allows
the loading of credentials & configuration from a file.  The actual code itself
would only need to know about the name used in the configuration file. This
aims to make it simpler for operations teams to manage database credentials.

A simple tutorial that compliments this documentation and explains converting 
an existing DBIx::Class Schema to use this software to manage credentials can 
be found at L<http://www.symkat.com/credential-management-in-dbix-class>

=head1 SYNOPSIS

    /etc/dbic.yaml

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

    use base 'DBIx::Class::Schema::Config';
    __PACKAGE__->config_paths([( '/var/www/secret/dbic', '/opt/database' )]);

The above code would have I</var/www/secret/dbic.*> and I</opt/database.*> 
searched, in that order.  As above, the first credentials found would be used.  
This will replace the files originally searched for, not add to them.

=head1 USE SPECIFIC CONFIG FILES

If you would rather explicitly state the configuration files you

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

Historical Note: This class accepts numerous ways to connect to DBIC that would
otherwise not be valid.  These connection methods are discouraged but tested for
and kept for compatibility with earlier versions.  For valid ways of connecting to DBIC
please see L<https://metacpan.org/pod/DBIx::Class::Storage::DBI#connect_info>

=head2 filter_loaded_credentials

Override this function if you want to change the loaded credentials before
they are passed to DBIC.  This is useful for use-cases that include decrypting
encrypted passwords or making programmatic changes to the configuration before
using it.

    sub filter_loaded_credentials {
        my ( $class, $loaded_credentials, $connect_args ) = @_;
        ...
        return $loaded_credentials;
    }

C<$loaded_credentials> is the structure after it has been loaded from the
configuration file.  In this case, C<$loaded_credentials-E<gt>{user}> eq
B<WalterWhite> and C<$loaded_credentials-E<gt>{dsn}> eq
B<DBI:mysql:database=students;host=%s;port=3306>.

C<$connect_args> is the structure originally passed on C<-E<gt>connect()>
after it has been turned into a hash.  For instance,
C<-E<gt>connect('DATABASE', 'USERNAME')> will result in

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

    package My::Schema
    use warnings;
    use strict;
    use base 'DBIx::Class::Schema::Config';

    sub filter_loaded_credentials {
        my ( $class, $loaded_credentials, $connect_args ) = @_;
        if ( $loaded_credentials->{dsn} =~ /\%s/ ) {
            $loaded_credentials->{dsn} = sprintf( $loaded_credentials->{dsn},
                $connect_args->{hostname});
        }
    }

    __PACKAGE__->load_classes;
    1;

Then the connection could be done with
C<$Schema-E<gt>connect('DATABASE', { hostname => 'my.hostname.com' });>

See L</load_credentials> for more complex changes that require changing
how the configuration itself is loaded.

=head2 load_credentials

Override this function to change the way that L<DBIx::Class::Schema::Config>
loads credentials.  The function takes the class name, as well as a hashref.

If you take the route of having C<-E<gt>connect('DATABASE')> used as a key for
whatever configuration you are loading, I<DATABASE> would be
C<$config-E<gt>{dsn}>

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

            TraceLevel => 1
        }
    );

Would result in the following data structure as $config in
C<load_credentials($class, $config)>:

    {
        dsn             => "SomeTarget",
        user            => "Yuri",
        password        => "Yawny",
        TraceLevel      => 1,
    }

Currently, load_credentials will NOT be called if the first argument to
C<-E<gt>connect()> looks like a valid DSN.  This is determined by match
the DSN with C</^dbi:/i>.

The function should return the same structure.  For instance:

lib/DBIx/Class/Schema/Config.pm  view on Meta::CPAN

    use strict;
    use base 'DBIx::Class::Schema::Config';
    use LWP::Simple;
    use JSON

    # Load credentials from internal web server.
    sub load_credentials {
        my ( $class, $config ) = @_;

        return decode_json(
            get( "http://someserver.com/v1.0/database?key=somesecret&db=" .
                $config->{dsn}  ));

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

0.082821 2016-02-11 17:58 (UTC)
    * Fixes
        - Fix t/52leaks.t failures on compilerless systems (RT#104429)
        - Fix t/storage/quote_names.t failures on systems with specified Oracle
          test credentials while missing the optional Math::Base36
        - Fix test failures when DBICTEST_SYBASE_DSN is set (unnoticed change
          in error message wording during 0.082800 and a bogus test)
        - Remove largely obsolete test of SQLite view deployment (RT#111916)

    * Misc

 view release on metacpan or  search on metacpan

lib/DBIx/Config.pm  view on Meta::CPAN

    }

    my $config = $self->_make_config(@info);

    # Take responsibility for passing through normal-looking
    # credentials.
    $config = $self->default_load_credentials($config)
        unless $config->{dsn} =~ /dbi:/i;

    return $self->_dbi_credentials($config);
}

# Normalize arguments into a single hash.  If we get a single hashref,
# return it.
# Check if $user and $pass are hashes to support things like

lib/DBIx/Config.pm  view on Meta::CPAN

# DBI's ->connect expects 
# ( "dsn", "user", "password", { option_key => option_value } )
# this function changes our friendly hashref into this format.

sub _dbi_credentials {
    my ( $class, $config ) = @_;

    return (
        delete $config->{dsn},
        delete $config->{user},
        delete $config->{password},
        $config,
    );
}

sub default_load_credentials {
    my ( $self,  $connect_args ) = @_;
    
    # To allow overriding without subclassing, if you pass a coderef
    # to ->load_credentials, we will replace our default load_credentials
    # without that function.
    if ( $self->load_credentials ) {
        return $self->load_credentials->( $self, $connect_args );
    }
    
    require Config::Any; # Only loaded if we need to load credentials.

    # While ->connect is responsible for returning normal-looking
    # credential information, we do it here as well so that it can be
    # independently unit tested.
    return $connect_args if $connect_args->{dsn} =~ /^dbi:/i; 

lib/DBIx/Config.pm  view on Meta::CPAN

    my %cf_opts = ( use_ext => 1 );
    my $ConfigAny = @{$self->config_files}
        ? Config::Any->load_files({ files => $self->config_files, %cf_opts })
        : Config::Any->load_stems({ stems => $self->config_paths, %cf_opts });

    return $self->default_filter_loaded_credentials(
        $self->_find_credentials( $connect_args, $ConfigAny ),
        $connect_args
    );

}

# This will look through the data structure returned by Config::Any
# and return the first instance of the database credentials it can
# find.
sub _find_credentials {
    my ( $class, $connect_args, $ConfigAny ) = @_;
    
    for my $cfile ( @$ConfigAny ) {
        for my $filename ( keys %$cfile ) {
            for my $database ( keys %{$cfile->{$filename}} ) {

lib/DBIx/Config.pm  view on Meta::CPAN

            }
        }
    }
}

sub default_filter_loaded_credentials {
    my ( $self, $loaded_credentials,$connect_args ) = @_;
    if ( $self->filter_loaded_credentials ) {
        return $self->filter_loaded_credentials->( 
            $self, $loaded_credentials,$connect_args 
        );
    }
    return $loaded_credentials;
}

# Assessors
sub config_paths {
    my $self = shift;

lib/DBIx/Config.pm  view on Meta::CPAN

    my $self = shift;
    $self->{config_files} = shift if @_;
    return $self->{config_files};
}

sub filter_loaded_credentials {
    my $self = shift;
    $self->{filter_loaded_credentials} = shift if @_;
    return $self->{filter_loaded_credentials};
}

sub load_credentials {
    my $self = shift;
    $self->{load_credentials} = shift if @_;
    return $self->{load_credentials};
}

1;

=head1 NAME

DBIx::Config - Manage credentials for DBI

=head1 DESCRIPTION

DBIx::Config wraps around L<DBI> to provide a simple way of loading database 
credentials from a file.  The aim is make it simpler for operations teams to 
manage database credentials.  

=head1 SYNOPSIS

Given a file like C</etc/dbi.yaml>, containing:

lib/DBIx/Config.pm  view on Meta::CPAN

            TraceLevel => 1, 
        },
    );

For cases where you may use something like C<DBIx::Connector>, a
method is provided that will simply return the connection credentials:


    !/usr/bin/perl
    use warnings;
    use strict;

lib/DBIx/Config.pm  view on Meta::CPAN

    my $conn = DBIx::Connector->new(DBIx::Config->connect_info("MY_DATABASE"));

=head1 CONFIG FILES

By default the following configuration files are examined, in order listed,
for credentials.  Configuration files are loaded with L<Config::Any>.  You
should append the extention that Config::Any will recognize your file in
to the list below.  For instance ./dbic will look for files such as
C<./dbic.yaml>, C<./dbic.conf>, etc.  For documentation on acceptable files
please see L<Config::Any>.  The first file which has the given credentials 
is used.

=over 4

=item * C<$ENV{DBIX_CONFIG_DIR}> . '/dbic', 

lib/DBIx/Config.pm  view on Meta::CPAN

    my $dbh = $DBI->connect( "MY_DATABASE" );

This would check, in order, C<dbcreds> in the current directory, and then C</etc/dbcreds>,
checking for valid configuration file extentions appended to the given file.

=head2 filter_loaded_credentials

You may want to change the credentials that have been loaded, before they are used
to connect to the DB.  A coderef is taken that will allow you to make programatic
changes to the loaded credentials, while giving you access to the origional data
structure used to connect.

    DBIx::Config->new(
        filter_loaded_credentials => sub {
            my ( $self, $loaded_credentials, $connect_args ) = @_;
            ...
            return $loaded_credentials;
        }
    )

Your coderef will take three arguments.  

=over 4

=item * C<$self>, the instance of DBIx::Config your code was called from. C

=item * C<$loaded_credentials>, the credentials loaded from the config file.

=item * C<$connect_args>, the normalized data structure of the inital C<connect> call.

=back

Your coderef should return the same structure given by C<$loaded_credentials>.

As an example, the following code will use the credentials from C</etc/dbi>, but
use its a hostname defined in the code itself.

C</etc/dbi> (note C<host=%s>):

    MY_DATABASE:

lib/DBIx/Config.pm  view on Meta::CPAN

    use strict;
    use DBIx::Config;

    my $dbh = DBIx::Config->new(
        # If we have %s, replace it with a hostname.
        filter_loaded_credentials => sub {
            my ( $self, $loaded_credentials, $connect_args ) = @_;

                if ( $loaded_credentials->{dsn} =~ /\%s/ ) {
                    $loaded_credentials->{dsn} = sprintf( 
                        $loaded_credentials->{dsn}, $connect_args->{hostname} 
                    );
                }
                return $loaded_credentials;
            }
        )->connect( "MY_DATABASE", { hostname => "127.0.0.1" } );

=head2 load_credentials

Override this function to change the way that DBIx::Config loads credentials. 
The function takes the class name, as well as a hashref.

If you take the route of having ->connect('DATABASE') used as a key for whatever 
configuration you are loading, DATABASE would be $config->{dsn}

lib/DBIx/Config.pm  view on Meta::CPAN

        { 
            TraceLevel => 1 
        } 
    );

Would result in the following data structure as $config in load_credentials($self, $config):

    {
        dsn             => "SomeTarget",
        user            => "Yuri",
        password        => "Yawny",
        TraceLevel      => 1,
    }

Currently, load_credentials will NOT be called if the first argument to ->connect() 
looks like a valid DSN. This is determined by match the DSN with /^dbi:/i.

The function should return the same structure. For instance:

    #!/usr/bin/perl

lib/DBIx/Config.pm  view on Meta::CPAN

    use DBIx::Config;
    use LWP::Simple;
    use JSON;

    my $DBI = DBIx::Config->new(
        load_credentials => sub {
            my ( $self, $config ) = @_;
            
            return decode_json( 
                get( "http://someserver.com/v1.0/database?name=" . $config->{dsn} )
            );

 view release on metacpan or  search on metacpan

lib/DBIx/Cookbook.pm  view on Meta::CPAN

=head2 The sakila database is installed automatically

Just FYI, there is a C<sakila> target that runs automatically when you
run C<make>. This target downloads the sakila database and loads it
into MySQL. It also stores the MySQL auth credentials in
F<lib/DBI/Cookbook/DBH.pm>. 

If you ever want to run it separately simply type

  make sakila

 view release on metacpan or  search on metacpan

t/common-sqlserver.t  view on Meta::CPAN

        |computed_columns
        |configurations
        |conversation_endpoints
        |conversation_groups
        |conversation_priorities
        |credentials
        |crypt_properties
        |cryptographic_providers
        |data_spaces
        |database_audit_specification_details
        |database_audit_specifications

t/common-sqlserver.t  view on Meta::CPAN

        |server_event_session_targets
        |server_event_sessions
        |server_events
        |server_file_audits
        |server_permissions
        |server_principal_credentials
        |server_principals
        |server_role_members
        |server_sql_modules
        |server_trigger_events
        |server_triggers

 view release on metacpan or  search on metacpan

lib/DBIx/DWIW.pm  view on Meta::CPAN

                ## etc.) DBI::ProxyServer just reports "Unexpected EOF from
                ## server". Let's give the user a hint as to what that
                ## might mean.
                ##
                if ($ERROR =~ m/^Cannot log in to DBI::ProxyServer: Unexpected EOF from server/) {
                    $ERROR =    "Cannot log in via DBI::ProxyServer: Unexpected EOF from server (check user's MySQL credentials and privileges)";
                }
                if (not $NoAbort) {
                    die $ERROR;
                }
                elsif (not $Quiet) {

 view release on metacpan or  search on metacpan

lib/DBIx/DataStore.pm  view on Meta::CPAN

    my $db = DBIx::DataStore->new({ config => $config });

=head2 Configuring Database Passwords

Because DBIx::DataStore uses the normal DBI/DBD layers underneath, all the
usual methods of locating and presenting database credentials to the
appropriate database server are available.  This includes methods such as the
C<.pgpass> file for PostgreSQL and equivalents for other RDBMSes. If your
DBIx::DataStore configuration does not include a C<pass> attribute for a given
database host, these alternate methods will be used as long as they are
properly configured.

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

* Mon May 21 11:38:02 2007 CEST

DBIx::Easy v0.17 released

* Fri May 18 17:27:15 2007 CEST
(Easy.pm): MySQL 5 has a different message for bad credentials
commit only if AutoCommit is turned off to avoid spurious warnings

* Fri May 18 00:17:37 2007 CEST
(Easy.pm): fixed now method for Postgresql