Ignore 'extra' in Twitter auth response to avoid CookieOverflow. Fixes #145.

[tbloncar]

This addresses #145.

[lynndylanhurley]

Thx @tbloncar!!

[lynndylanhurley]

You're now an official contributor!

[tbloncar]

Thanks, @lynndylanhurley.

[lynndylanhurley]

I just pushed version 0.1.32.beta7. Please pull it down and confirm that it works ok.

[nicolas-besnard]

What does it change to remove the 'extra' parameter ?
On Thu 12 Mar 2015 at 08:54 Lynn Dylan Hurley [email protected]
wrote:

I just pushed version 0.1.32.beta7. Please pull it down and confirm that
it works ok.

—
Reply to this email directly or view it on GitHub
#179 (comment)
.

[lynndylanhurley]

The schema description is here. I'm not sure exactly - I think it varies by provider.

[nicolas-besnard]

I'm not sure this is the right think to do. I'm using this extra parameters on my projects.
This extra parameters is seeded with data depending on the scope you use such as scope: 'email, user_birthday, user_about_me' when you use Facebook (for example).

[tbloncar]

@nicolas-besnard Your point makes sense to me; I think the issue here is that the default behavior for Twitter auth (before this change) was a raise of ActionDispatch::Cookies::CookieOverflow. While this change ameliorates that issue, I see that it may result in missing some of the data you mentioned.

One alternative to this solution is making some mention of using an alternate session store (like ActiveRecord store) in the README. This would be "as needed," of course. Another option might be using except('extra') for only the Twitter callback (for now).

[c0mrade]

Yeah I got the same CookieOverflow from google too, and I'm using a database as a data store to solve that problem. It all depends what info are you looking to get (as Nicolas already explained). You may or may get the same issue. Yeah doesn't sound right to restrict people who want to get that extra info (I myself don't use or need it), just thinking out loud.

[nicolas-besnard]

As this is an API, we don't need Cookie or Session. I just think the
implementation of Omniauth is not valid on this gem. I'll dig this this
weekend.

On Thu, Mar 12, 2015 at 3:35 PM Emir Ibrahimbegovic <
[email protected]> wrote:

Yeah I got the same CookieOverflow from google too, and I'm using a
database as a data store. It all depends what info are you looking to get.
It may or may not resolve in the issue. Yeah doesn't sound right to
restrict people who want to get that extra info (I myself don't use or need
it), just thinking out loud.

—
Reply to this email directly or view it on GitHub
#179 (comment)
.

[c0mrade]

Yes that was my initial thought but I had some errors and had to deliver something, so I ended up adding session middleware so the code works, thanks for reminding me I will need to remove that.
(Talking about my project, not on the actual repo here)

[medaglia]

I too am using omniauth_facebook and require the data passed via extra (age_range, gender, etc). I wasn't able to override redirect_callbacks (whereas i have no problem overriding omniauth_failure). Does anyone have any any good suggestions? Right now I'm torn between...

1. branching omniauth_facebook to pass the data through info instead of extra
2. branching devise_token_auth to keep extra