This change adds three new configuration variables to third_party_auth's LinkedIn provider:
* SOCIAL_AUTH_LINKEDIN_OAUTH2_SCOPE,
* SOCIAL_AUTH_LINKEDIN_OAUTH2_FIELD_SELECTORS,
* SOCIAL_AUTH_LINKEDIN_OAUTH2_EXTRA_DATA
Being able to configure these additional settings is useful if you want
the LinkedIn provider to pre-populate the email field when a new user
registers via the linkedin provider.
The Google provider prepoulates the email field by default, but if you
want LinkedIn to do the same, these two settings should be set to:
SOCIAL_AUTH_LINKEDIN_OAUTH2_SCOPE = ['r_basicprofile', 'r_emailaddress']
SOCIAL_AUTH_LINKEDIN_OAUTH2_FIELD_SELECTORS = ['email-address']
For more info see:
http://psa.matiasaguirre.net/docs/backends/linkedin.html
Declare variables locally
- The `allSections` variable was leaking into the global scope, due to a
typo in the declaration.
- `dataProcessed` can be declared more narrowly within the callback.
Clean up fixtures automatically between tests
- Nesting test fixture markup within a DIV allows Jasmine to
automatically restore the fixture to a clean state between each test
run.
Fix id attribute collision typo
- This looks like a copy/pasta gone wrong; the two test INPUT elements
were both declared with the same id, `input_1`.
Remove trailing whitespace
The behavior previously tested here was to check that if a JSInput
element was marked as not processed, re-walking the DOM *should* have
reinitialized it. Unfortunately, this behavior is not supported by the
underlying JSChannel library. In fact, if JSChannel detects an existing
channel with the same origin and scope, it throws an uncaught exception,
leaving the DOM in a "broken" state.
JSInput will prevent duplicates from being added, as long as we don't
manually update the `data-processed` attribute. This behavior is already
being tested.
Select DOM elements with wildcard syntax
- DOM lookups were being done with non-existent literal selectors, so it
was returning empty lists. As assertions were to be made while
iterating over the list of elements, nothing was actually being
verified.
- Common code has been centralized in the setup function. By declaring
CSS selectors once, we minimize the odds of inadvertently using the
wrong selector, as happened here.
- Had these tests actually been iterating over a non-empty list, this
would have thrown undefined exceptions. jQuery.each calls its handler
with an index and an item/object as the arguments. However, the object
is a DOM-object, not a jQuery-object. These tests break, as they had
assumed the latter.
This test currently fails, meaning that the existing tests weren't
testing what they claimed.
Assertions are made for each element returned by the CSS selectors.
However, the selectors are assumed to be wildcard matches, but are
actually literal selectors. As there are no matched elements, this
causes the assertions to be (silently) checked zero times, without
failure.
