Skip to content
This repository has been archived by the owner on Dec 8, 2020. It is now read-only.

Commit

Permalink
Remove omniauth integration
Browse files Browse the repository at this point in the history
  • Loading branch information
@binarylogic
binarylogic committed Sep 13, 2017
1 parent 5a0cc17 commit ff4581b
Show file tree
Hide file tree
Showing 3 changed files with 45 additions and 101 deletions.
7 changes: 6 additions & 1 deletion CHANGELOG.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,9 +6,14 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).

## [Unreleased]
### Changed

- Omniauth integration was removed since it only captures user context during the Authentication
phase. Omniauth does not persist sessions. As such, the integration is extremely low value
and could cause unintended issues.

## [2.2.0] - 2017-09-13
## Changed
### Changed

- The default HTTP log device queue type was switched to a
`Timber::LogDevices::HTTP::FlushableDroppingSizedQueue` instead of a `::SizedQueue`. In the
Expand Down
118 changes: 35 additions & 83 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,14 +5,17 @@
[![Build Status](https://travis-ci.org/timberio/timber-ruby.svg?branch=master)](https://travis-ci.org/timberio/timber-ruby)
[![Code Climate](https://codeclimate.com/github/timberio/timber-ruby/badges/gpa.svg)](https://codeclimate.com/github/timberio/timber-ruby)

[Timber](https://timber.io) is a cloud-based logging system that integrates directly with your Ruby
app through this library, capturing context and metadata without parsing. This produces rich, clean,
readable logs that are easier to search and use:
Timber for Ruby is a drop in replacement for your Ruby logger that
[unobtrusively augments](https://timber.io/docs/concepts/structuring-through-augmentation) your
logs with [rich metadata and context](https://timber.io/docs/concepts/metadata-context-and-events)
making them [easier to search, use, and read](#get-things-done-with-your-logs). It pairs with the
[Timber console](#the-timber-console) to deliver a tailored Ruby logging experience designed to make
you more productive.

1. [**Installation** - One command: `bundle exec timber install`](#installation)
2. [**Usage** - Simple yet powerful API](#usage)
2. [**Usage** - Simple & powerful API](#usage)
3. [**Integrations** - Automatic context and metadata for your existing logs](#integrations)
4. [**The Timber Console** - Designed for Ruby developers](#the-timber-console)
4. [**The Timber Console** - Designed for applications & developers](#the-timber-console)
5. [**Get things done with your logs 💪**](#get-things-done-with-your-logs)


Expand All @@ -24,9 +27,11 @@ readable logs that are easier to search and use:
gem 'timber', '~> 2.1'
```

2. In your `shell`, run `bundle install`
2. In your `shell`, run:

3. In your `shell`, run `bundle exec timber install`
```
bundle install && bundle exec timber install
```


## Usage
Expand All @@ -43,51 +48,37 @@ logger.error("Error message")
logger.fatal("Fatal message")
```

We encourage standard / traditional log messages for non-meaningful events. And because Timber
[augments](https://timber.io/docs/concepts/structuring-through-augmentation) your logs with
metadata, you don't have to worry about making every log structured!
1. [Search it](https://timber.io/docs/app/console/searching) with queries like: `error message`
2. [Alert on it](https://timber.io/docs/app/console/alerts) with threshold based alerts
3. [View this event's metadata and context](https://timber.io/docs/app/console/view-metdata-and-context)
[...read more in our docs](https://timber.io/docs/languages/ruby/usage/basic-logging)
---
</p></details>
<details><summary><strong>Logging events (structured data)</strong></summary><p>
Logging events allows you to log structured data without sacrificing readability or worrying about
structured data name or type conflicts. Keep in mind, Timber defines common events in the
[`Timber::Events`](http://www.rubydoc.info/github/timberio/timber-ruby/Timber/Events) namespace,
which are automatically logged for you through our [integrations](#integrations). You should not
have to maually log events defined there except in special circumstances.
### How to use it
Log structured data without sacrificing readability:
```ruby
logger.warn "Payment rejected", payment_rejected: {customer_id: "abcd1234", amount: 100, reason: "Card expired"}
```
1. [Search it](https://timber.io/docs/app/console/searching) with queries like: `type:payment_rejected` or `payment_rejected.amount:>100`
2. [Alert on it](https://timber.io/docs/app/console/alerts) with threshold based alerts
3. [Graph & visualize it](https://timber.io/docs/app/console/graphing)
4. [View this event's data and context](https://timber.io/docs/app/console/view-metdata-and-context)
5. ...read more in our [docs](https://timber.io/docs/languages/ruby/usage/custom-events)

...[read more in our docs](https://timber.io/docs/languages/ruby/usage/custom-events)

---

</p></details>

<details><summary><strong>Setting context</strong></summary><p>

Context is amazingly powerful, think of it like join data for your logs. It represents the
environment when the log was written, allowing you to relate logs so you can easily segment them.
It's how Timber is able to accomplish features like
[tailing users](https://timber.io/docs/app/console/tail-a-user) and
[tracing HTTP requests](https://timber.io/docs/app/console/trace-http-requests).
Keep in mind, Timber defines common contexts in the
[`Timber::Contexts`](http://www.rubydoc.info/github/timberio/timber-ruby/Timber/Contexts) namespace,
which are automatically set for you through our [integrations](#integrations). You should not
have to maually set these contexts except in special circumstances.
### How to use it
Add shared structured data across your logs:

```ruby
Timber.with_context(job: {id: 123}) do
Expand All @@ -99,38 +90,24 @@ end

1. [Search it](https://timber.io/docs/app/console/searching) with queries like: `job.id:123`
2. [View this context when viewing a log's metadata](https://timber.io/docs/app/console/view-metdata-and-context)
3. ...read more in our [docs](https://timber.io/docs/languages/ruby/usage/custom-context)
...[read more in our docs](https://timber.io/docs/languages/ruby/usage/custom-context)
---
</p></details>
<details><summary><strong>Metrics & Timings</strong></summary><p>
<details><summary><strong>Metrics, Timings, & Tracing</strong></summary><p>
Aggregates destroy details, events tell stories. With Timber, logging metrics and timings is simply
[logging an event](https://timber.io/docs/languages/ruby/usage/custom-events). Timber is based on
modern big-data principles and can aggregate inordinately large data sets in seconds. Logging
events (raw data as it exists), gives you the flexibility in the future to segment and aggregate
your data any way you see fit. This is superior to choosing specific paradigms before hand, when
you are unsure how you'll need to use your data in the future.
### How to use it
Below is a contrived example of timing a background job:
Time code blocks:
```ruby
timer = Timber.start_timer
# ... code to time ...
logger.info("Processed background job", background_job: {time_ms: timer})
```
And of course, `time_ms` can also take a `Float` or `Fixnum`:
```ruby
logger.info("Processed background job", background_job: {time_ms: 45.6})
```
Lastly, metrics aren't limited to timings. You can capture any metric you want:
Log generic metrics:
```ruby
logger.info("Credit card charged", credit_card_charge: {amount: 123.23})
Expand All @@ -139,8 +116,8 @@ logger.info("Credit card charged", credit_card_charge: {amount: 123.23})
1. [Search it](https://timber.io/docs/app/console/searching) with queries like: `background_job.time_ms:>500`
2. [Alert on it](https://timber.io/docs/app/console/alerts) with threshold based alerts
3. [View this log's metadata in the console](https://timber.io/docs/app/console/view-metdata-and-context)
4. ...read more in our [docs](https://timber.io/docs/languages/ruby/usage/metrics-and-timings)

...[read more in our docs](https://timber.io/docs/languages/ruby/usage/metrics-and-timings)

</p></details>

Expand All @@ -152,20 +129,14 @@ Below are a few popular configuration options, for a comprehensive list, see

<details><summary><strong>Logrageify. Silence noisy logs.</strong></summary><p>

Timber allows you to silence noisy logs that aren't of value to you, just like
[lograge](https://github.com/roidrage/lograge). As such, we've provided a convenience configuration
option for anyone transitioning from lograge.
### How to use it
Silence noisy logs that aren't of value to you, just like
[lograge](https://github.com/roidrage/lograge):
```ruby
# config/initializers/timber.rb
Timber.config.logrageify!()
```
### How it works
It turns this:
```
Expand All @@ -182,18 +153,7 @@ Completed 200 OK in 79ms (Views: 78.8ms | ActiveRecord: 0.0ms)
Into this:
```
Get "/" sent 200 OK in 79ms @metadata {...}
```
Internally this is equivalent to:
```ruby
# config/initializers/timber.rb
Timber.config.integrations.action_controller.silence = true
Timber.config.integrations.action_view.silence = true
Timber.config.integrations.active_record.silence = true
Timber.config.integrations.rack.http_events.collapse_into_single_event = true
Get "/" sent 200 OK in 79ms
```
### Pro-tip: Keep controller call logs (recommended)
Expand Down Expand Up @@ -222,11 +182,8 @@ For a full list of integration settings, see
<details><summary><strong>Silence specific requests (LB health checks, etc)</strong></summary><p>
Silencing noisy requests can be helpful for silencing load balance health checks, bot scanning,
or activity that generally is not meaningful to you.
### How to use it
The following will silence all `[GET] /_health` requests:
or activity that generally is not meaningful to you. The following will silence all
`[GET] /_health` requests:
```ruby
# config/initializers/timber.rb
Expand All @@ -247,12 +204,10 @@ The first parameter being the traditional Rack env hash, the second being a
<details><summary><strong>Capture custom user context</strong></summary><p>
By default Timber automatically captures user context for most of the popular authentication
libraries (Devise, Omniauth, and Clearance). See
libraries (Devise, and Clearance). See
[Timber::Integrations::Rack::UserContext](http://www.rubydoc.info/github/timberio/timber-ruby/Timber/Integrations/Rack/UserContext)
for a complete list.
### How to use it
In cases where you Timber doesn't support your strategy, or you want to customize it further,
you can do so like:

Expand Down Expand Up @@ -284,8 +239,6 @@ end
[Timber::Contexts::Release](http://www.rubydoc.info/github/timberio/timber-ruby/Timber/Contexts/Release)
tracks the current application release and version.

### How to use it

If you're on Heroku, simply enable the
[dyno metadata](https://devcenter.heroku.com/articles/dyno-metadata) feature. If you are not,
set the following environment variables and this context will be added automatically:
Expand All @@ -304,7 +257,7 @@ All variables are optional, but at least one must be present.
## Integrations
Timber integrates with popular frameworks and libraries to capture context and metadata you
couldn't otherwise. This automatically upgrades logs produced by these libraries, making them
couldn't otherwise. This automatically augments logs produced by these libraries, making them
[easier to search and use](#do-amazing-things-with-your-logs). Below is a list of libraries we
support:

Expand All @@ -313,7 +266,6 @@ support:
* [**Rack**](https://timber.io/docs/languages/ruby/integrations/rack)
* [**Devise**](https://timber.io/docs/languages/ruby/integrations/devise)
* [**Clearance**](https://timber.io/docs/languages/ruby/integrations/clearnace)
* [**Omniauth**](https://timber.io/docs/languages/ruby/integrations/omniauth)
* [**Warden**](https://timber.io/docs/languages/ruby/integrations/devise)
* Platforms
* [**Heroku**](https://timber.io/docs/languages/ruby/integrations/heroku)
Expand All @@ -324,7 +276,7 @@ support:

## Get things done with your logs

Logging features every developer needs:
Logging features designed to help developers get more done:

1. [**Powerful searching.** - Find what you need faster.](https://timber.io/docs/app/console/searching)
2. [**Live tail users.** - Easily solve customer issues.](https://timber.io/docs/app/console/tail-a-user)
Expand Down
21 changes: 4 additions & 17 deletions lib/timber/integrations/rack/user_context.rb
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,8 @@ module Rack
# This is a Rack middleware responsible for setting the user context.
# See {Timber::Contexts::User} for more information on the user context.
#
# ## Why a Rack middleware?
#
# We use a Rack middleware because we want to set the user context as early as
# possible, and before the initial incoming request log line:
#
Expand All @@ -29,7 +31,6 @@ module Rack
# automatically set the user context for you.
#
# * Devise, or any Warden based authentication strategy
# * Omniauth
# * Clearance
#
# Or, you can use your own custom authentication, see the {.custom_user_context}
Expand All @@ -47,7 +48,7 @@ class << self
#
# @example Setting your own custom user context
# Timber::Integrations::Rack::UserContext.custom_user_hash = lambda do |rack_env|
# rach_env['my_custom_key'].user
# rack_env['my_custom_key'].user
# end
def custom_user_hash=(proc)
if proc && !proc.is_a?(Proc)
Expand Down Expand Up @@ -78,14 +79,10 @@ def call(env)
private
def get_user_hash(env)
# The order is relevant here. The 'warden' key can be set, but
# not return a user, in which case the user data might be in the omniauth
# data.
# not return a user, in which case the user data might be in another key.
if self.class.custom_user_hash.is_a?(Proc)
Timber::Config.instance.debug { "Obtaining user context from the custom user hash" }
self.class.custom_user_hash.call(env)
elsif (auth_hash = env['omniauth.auth'])
Timber::Config.instance.debug { "Obtaining user context from the omniauth auth hash" }
get_omniauth_user_hash(auth_hash)
elsif env[:clearance] && env[:clearance].signed_in?
Timber::Config.instance.debug { "Obtaining user context from the clearance user" }
user = env[:clearance].current_user
Expand All @@ -99,16 +96,6 @@ def get_user_hash(env)
end
end

def get_omniauth_user_hash(auth_hash)
info = auth_hash['info']

{
id: auth_hash['uid'],
name: info['name'],
email: info['email']
}
end

def get_user_object_hash(user)
id = try_user_id(user)
name = try_user_name(user)
Expand Down

0 comments on commit ff4581b

Please sign in to comment.