ac/login-convenience-bundle
Symfony bundle that streamlines JSON API authentication with OpenID via FpOpenIdBundle. Includes a base User class, JSON login/logout endpoints, auth-header session storage (no cookies), reload-less OpenID flow support, trusted providers, and dummy login mode.
Simplifies authentication for a Symfony server providing a JSON web API.
Provides the following on top of Fp/OpenIdBundle:
ac/login-convenience-bundle with composerac_login_convenience:
secured_paths:
- /important-stuff
ac_login_convenience:
resource: "."
type: "ac_login_convenience_routes"
framework:
session:
storage_id: ac_login_convenience.session.storage.auth_header
Add users to your system with the create-user command. You can specify an
OpenID identity path when doing so, which allows them to log in via that
identity.
If you don't want to specify the identity in advance, add entries to the
ac_login_convenience.trusted_providers config
option for any OpenID providers that you trust to authenticate previously
unknown users:
ac_login_convenience:
trusted_providers:
- https://somebody.trustworthy.com/openid
Any user who logs in via a trusted provider can have that identity matched via email address to existing users you've created. This does require that the provider supply the user's email via the "contact/email" AX field, but this is pretty common.
Alternately, you can make your own OpenID registration system. After verifying
in some secure way that an identity URL really does belong to a user, you can call
the associateIdentityWithUser method on ac_login_convenience.openid_user_manager
to allow logins for that user with that identity.
These can be specified under the ac_login_convenience config section:
dummy_mode: If true, then instead of actually making OpenID checks
on logins, the user can simply pick from a list of all the users
in the database. This is useful for the dev environment, but
obviously it should not be used on production systems.
db_driver: Defaults to orm, meaning that users and identities are
accessed via Doctrine ORM. Alternately, you can specify mongodb.
user_model_class: You must use your own User class; specify the fully namespaced
name of the class here. You should derive it from Entity\AbstractEntityUser
or Document\AbstractDocumentUser, depending on which db_driver setting
you are using.
api_keys: An optional hash map from user email addresses to API keys.
If supplied, then clients can use an "Authorization: Key foobar" header
to directly access your app as the given user with key "foobar", without
having to go through the full OpenID-authentication and session-creation process.
How can I help you explore Laravel packages today?