- How do I install jhaoda/socialite-odnoklassniki in a Laravel app?
- Install it with Composer using composer require jhaoda/socialite-odnoklassniki. The package's service provider is auto-discovered, so you do not need to register it manually in config/app.php. After that you add an odnoklassniki block to config/services.php and define the redirect and callback routes in your app, exactly as you would for GitHub or Google. No migrations or config publishing steps are required.
- What configuration keys does the Odnoklassniki driver need in config/services.php?
- At minimum you need client_id, client_secret, and redirect for the OAuth2 handshake. Odnoklassniki also requires an application_key and application_secret, because its API calls (not just the token exchange) must be signed. Set these from your OK.ru application settings, and keep the secrets in environment variables rather than committing them. Missing or mismatched application credentials are the most common cause of signature errors at runtime.
- Does this package support Laravel 10, 11, or 12 and PHP 8.2 or 8.3?
- Compatibility is unverified: the last tagged release was 2021-03-19, roughly four years ago, and there is no published CI matrix covering modern Laravel or PHP versions. The illuminate/support and socialite version constraints are likely to conflict with Laravel 10, 11, or 12, in which case Composer will refuse to install rather than fail silently. Check with composer why-not before planning any work, and treat a working install as something you must prove rather than assume. If it does not install cleanly, plan to fork and relax the constraints.
- How do I log a user in with Socialite::driver('odnoklassniki')?
- Use the standard Socialite flow: return Socialite::driver('odnoklassniki')->redirect() from a login route, then in the callback call Socialite::driver('odnoklassniki')->user() to get the profile. The package registers itself through Socialite::extend('odnoklassniki', ...), which is the framework-sanctioned extension point, so the call site is identical to built-in providers. Because of that, you can hide it behind your own SocialAuthProvider interface and swap providers later without touching controllers. Session handling and state CSRF remain Socialite's responsibility, which keeps the driver's surface small.
- Why does Odnoklassniki require an application_key and a signature (sig), and is MD5 a security problem?
- Odnoklassniki's OAuth2 is not textbook OAuth2: both the token exchange and authenticated API calls require an application_key plus a sig parameter computed as an MD5 hash over the sorted request parameters and your application secret. MD5 is mandated by the provider, not chosen by the package, so document that in any security review so it is not flagged as a package defect. This custom signing logic is the genuinely non-trivial part of the driver and the main reason not to hand-roll it. It also means the driver is pinned to OK's legacy signing scheme, which will silently break if the provider migrates.
- What should I use as the user identity if Odnoklassniki returns no email address?
- OK.ru frequently returns no verified email, so do not assume email-keyed user creation will work. Confirm the driver's field mapping against a real response, then design an account-linking and verification fallback keyed on the Odnoklassniki user ID. A common pattern is to create the account with a placeholder identity and prompt the user to add and verify an email afterwards. Decide this before you build the callback, because retrofitting an identity key later is painful.
- Does the package handle token refresh and token expiry?
- Socialite's driver API centers on the authorization-code exchange and user retrieval, so refresh and expiry handling is limited by the abstraction rather than by this driver alone. The evaluation flags token refresh, token expiry, and signature-signed authenticated calls as items to verify by reading the driver source rather than trusting the README. If you need long-lived access to OK.ru APIs, plan to store the access token and handle expiry yourself. Do not assume the package gives you a refresh flow out of the box.
- Is jhaoda/socialite-odnoklassniki still maintained, and what are the alternatives?
- It has a last release date of 2021-03-19, roughly 41 GitHub stars, a bus factor of one, and no evidence of a CI matrix or recent issue triage. Upstream is unlikely to absorb your fixes, so realistically you fork or vendor the package rather than depend on it being updated. The MIT license makes forking, patching, and internal redistribution clean, which substantially de-risks the staleness. The other alternative is a small in-house driver of roughly 200 to 300 lines, but you would be reimplementing the signing logic that makes this package worth using in the first place.
- Is it compliant to use Odnoklassniki (VK) as a login provider in production?
- Odnoklassniki is part of VK, which can carry sanctions, KYC, and cross-border data-transfer implications depending on your jurisdiction, including Russian 152-FZ data localization requirements. This is a legal and compliance review item, not an engineering one, and it should gate the decision before you spend time on a code spike. The package itself cannot mitigate any of that; it only implements the protocol. Get written clearance for VK-owned identity providers against your user base and data-residency obligations first.
- How do I test the Odnoklassniki login flow without real OK.ru credentials?
- Keep the driver behind your own thin interface and fake that interface in feature tests, asserting your redirect route, callback handling, state checks, and user-linking logic without hitting OK.ru. For the driver itself, mock at the HTTP layer and feed it canned token and profile responses that mirror real OK.ru payloads, including a response with no email. Because the driver is small and composed rather than deeply integrated, this is cheap to do. Also add one manual smoke test with real sandbox credentials, since the signature scheme is the part most likely to break.