Issue running in production only on Laravel 4 about sentry-laravel HOT 6 CLOSED

I would +1 the should be stored in .env.x.php git ignored files as this helps with per environment configuration of legacy laravel 4 applications.

However watch out for using plain getenv() for boolean/null/int values in Laravel 4, Laravel 5 has an env() function in helpers.php which translates strings provided by the php ENV variables back into their appropriate types.

A string getenv() of false for breadcrumbs.sql_bindings or user_context may evaluate to true accidentally enabling the feature. Also if getenv() fails it will return false which is handled better by the laravel helper function from memory.

For Laravel 4 I pulled out the env() function and put it into a polyfill composer library (https://github.com/zVPS/laravel-4-env-polyfill) which can be useful for setting the dsn & app configs in a Laravel 5 compatible way:

<?php
return [
    'dsn' => env('SERVICES_SENTRY_DSN', ''),
    // capture release as git sha
    'release' => trim(exec('git --git-dir ' . base_path('.git') . ' log --pretty="%h" -n1 HEAD')),
    // Capture bindings on SQL queries
    'breadcrumbs.sql_bindings' => env('SERVICES_SENTRY_SQL_BINDINGS', true),
    // Capture default user context
    'user_context' => env('SERVICES_SENTRY_USER_CONTEXT', true),
];

.env.local.php

    'SERVICES_SENTRY_DSN' => 'http://secure:thingy@localhost:6700/2',
    'SERVICES_SENTRY_SQL_BINDINGS' => 'true',
    'SERVICES_SENTRY_USER_CONTEXT' => 'true',

Hope this helps any peoples still on Laravel 4

from sentry-laravel.

The best way to do production only would be to log Sentry in all environments but only set DSN in production. This ensures you are running nearly the same code in dev and prod but disables reporting in dev.

from sentry-laravel.

@dcramer Thanks for your reply. I've just noticed the config file which is published in the L5 version references an env variable:

return array(
    'dsn' => env('SENTRY_DSN'),
    ..
);

I'd be happy to submit a pull request to add this functionality (using the core getenv function) to the L4 config file if you think this would make this approach clearer.

from sentry-laravel.

I think the only reason we don't use env in laravel 5 (as a default) is because I didn't know about getenv.

We should probably:

• add that
• add defensive hooks for the original issue you hit here

from sentry-laravel.

(Assuming you meant Laravel 4 here) The notion of environment variables did exist in Laravel 4 (https://laravel.com/docs/4.2/configuration#protecting-sensitive-configuration), but doesn't appear to be the preferred method of defining environment configuration.

I would say however that the DSN comes under the bracket of "sensitive configuration", and is certainly environment specific, and therefore better suits being stored in a git-ignored .env.X.php file, rather than in a committed config file

N.B. Laravel suggest using the $_ENV['prop'] retrieval method rather than the getenv() function. The latter will gracefully fail if no matching environment variable has been defined, which would be the desired behaviour in Sentry's case.

from sentry-laravel.

^ above is really good advice for people still running 4.x and who have not solved this issue another way. However we would be soon dropping 4.x support (the 0.8.x versions will keep working on L4) while moving forward with 5.x support so we are not going to address this in the package ourselfs.

from sentry-laravel.