- How do I install and configure taavi/laravel-socialite-mediawiki?
- Install it with Composer, then register the package's service provider if your Laravel version does not auto-discover it. Add a mediawiki block to config/services.php containing your consumer key, consumer secret, and wiki URL, then use Socialite's redirect and callback flow in your controller. The package is a thin Socialite driver, so no migrations or extra runtime services are required.
- Does this provider work with self-hosted MediaWiki installations?
- Yes, provided the wiki has the MediaWiki OAuth extension installed and you can register an OAuth consumer there. You configure the wiki base URL alongside the consumer credentials, so the provider is not limited to Wikimedia endpoints. Confirm the package's configuration keys in its source or README before wiring it into a non-Wikimedia wiki.
- Which Laravel, Socialite, and PHP versions are supported?
- Check the package's composer.json before adopting it, because Socialite has made breaking changes to provider signatures across major versions. The package is small and may lag behind the Socialite version implied by your Laravel release, especially Laravel 11 and 12 era installs. Pin compatible versions in CI and run the redirect and callback flow against your actual Laravel and PHP matrix.
- How do I register a MediaWiki OAuth consumer for this package?
- Create the consumer through Special:OAuthConsumerRegistration on the target wiki, which returns a client ID and secret. The callback URL must match exactly, including scheme, host, port, and trailing slash, or the wiki will reject the authorization request. On Wikimedia projects a wiki bureaucrat may need to approve the consumer, so plan for external review time rather than treating it as a pure coding task.
- What user information does the MediaWiki Socialite provider return?
- Expect a MediaWiki identity payload with fields such as a local user ID, username, and group memberships rather than an email address. Socialite returns this through its standard user contract, but the exact claims depend on the wiki and OAuth extension version. Inspect a real profile response before deciding which field to store as your application's user identifier.
- Should I key users on the MediaWiki local user ID or CentralAuth ID?
- On Wikimedia wikis the local user ID is per-wiki, so the same person can have different local IDs on different projects. The stable cross-wiki identifier is the CentralAuth ID, which is usually the safer key if your application spans multiple wikis. Keying on the wrong claim creates duplicate accounts that are painful to merge later, so treat this as a product-data decision, not just an implementation detail.
- Can the OAuth token from this provider be used to edit wiki pages or call the Action API?
- Do not assume so. MediaWiki OAuth 2.0 has historically been authentication-oriented, and this provider is positioned as a login driver rather than an API client. If your roadmap includes editing, uploading, or other authenticated Action API calls on a user's behalf, you likely need OAuth 1.0a with explicit grants, which is a different implementation. Verify token capabilities against the target wiki before promising write features.
- Is the package on Packagist, or do I need to add a VCS repository?
- The project is hosted on sourcehut, so first check whether it is published on Packagist. If it is not, add a Composer VCS repository entry pointing at the git.sr.ht URL and require the package by name. That approach works, but it means your dependency resolution and supply chain depend on a single forge rather than Packagist's ecosystem tooling.
- How can I test the MediaWiki OAuth redirect and callback locally?
- Register a development OAuth consumer whose callback URL matches your local host, port, scheme, and path exactly, because MediaWiki does not tolerate mismatches. A tunnel with a stable hostname is often easier than fighting localhost and port variations. Test both the redirect and callback paths plus the profile fetch, and keep a staging consumer separate from production credentials.
- Is this package production-ready, and what are the alternatives?
- The main risk is project health rather than code complexity: it has a single maintainer, limited external validation, and no obvious GitHub advisory or dependent coverage. For production, pin the version, review the provider code, add your own integration tests, and be prepared to fork or replace it after Socialite upgrades. Alternatives include writing a small custom Socialite provider or using a more actively maintained OAuth package if MediaWiki login is not central to your product.