Cast response_type to string when checking if it is set in params

[januszm]

Rails will provide params with indifferent access but that's not guaranteed with other frameworks.
Actually the automated test suite provides params object as a regular Hash

Omniauth sets keys as string, e.g. hash[field] = request.params[field.to_s] for the Developer strategy.

Adding strategy.options.response_type = :code alone to the test_callback_phase test is enough to trigger an error.

[januszm]

Unfortunately I cannot spend more time on this PR, so if you guys have any suggestions, please write in comments, or close this PR and start another one with an alternative solution to handling options.response_type passed as string or symbol in general (one, that cleans up the .to_s code duplication).

[januszm]

@m0n9oose this can be merged without the other pull request about token verification. It's easier to review them separately.

[m0n9oose]

@m0n9oose this can be merged without the other pull request about token verification. It's easier to review them separately.

Okay, as you wish. Can you transfer changes from #37 related to this PR?

[krzysiek1507]

Let me push my changes to handle this fix and id_token validation fix.

[januszm]

Guys this PR can be merged independently from others. If you want to apply some refactoring later, you can do it in another PR.

Regarding @m0n9oose 's idea to define the response_type method and cache the configuration value as a string, in all use cases the options.response_typevariable is or can be used as string. This means that it'd be more appropriate to change the README and propose a string variant for the option from now on.