Title: Wapu Auth – Social Login for WordPress and WooCommerce
Author: Victor Flores
Published: <strong>05.03.2026</strong>
Last modified: 12.08.2026

---

Поиск плагинов

![](https://ps.w.org/wapu-auth-social-login/assets/banner-772x250.png?rev=3612976)

![](https://ps.w.org/wapu-auth-social-login/assets/icon-256x256.png?rev=3612985)

# Wapu Auth – Social Login for WordPress and WooCommerce

 Автор: [Victor Flores](https://profiles.wordpress.org/victor88lm/)

[Скачать](https://downloads.wordpress.org/plugin/wapu-auth-social-login.2.1.0.zip)

 * [Детали](https://ru.wordpress.org/plugins/wapu-auth-social-login/#description)
 * [Отзывы](https://ru.wordpress.org/plugins/wapu-auth-social-login/#reviews)
 *  [Установка](https://ru.wordpress.org/plugins/wapu-auth-social-login/#installation)
 * [Разработка](https://ru.wordpress.org/plugins/wapu-auth-social-login/#developers)

 [Поддержка](https://wordpress.org/support/plugin/wapu-auth-social-login/)

## Описание

**Wapu Auth** adds Google and Facebook social login to WordPress and WooCommerce.
Provider OAuth processing is handled by the fixed **Wapu Auth Broker** at `https://
auth.wapuos.com`; provider client secrets and provider tokens never enter WordPress.

On activation or update, Wapu Auth queues an asynchronous, one-shot background connection.
An eligible public HTTPS site is registered, verified and checked without requiring
a normal registration button click. The worker uses an expiring lock, reuses a pending
broker challenge, retries temporary failures with bounded backoff and never rotates
or re-registers a verified current-origin credential. Local, private, non-HTTPS 
and cloned origins fail closed. A protected manual retry remains available when 
the host, firewall or cron system needs attention.

After the connection is verified, the plugin checks local HMAC signing, broker provider
availability, schema integrity, identity preflight and safe backfill before enabling
new broker login starts. Existing WordPress users, roles, WooCommerce customers,
orders and downloads are not recreated or deleted by this workflow.

#### Main Features

 * Google and Facebook login through full-page broker redirects and a closed provider
   registry.
 * Optional native Google One Tap/FedCM for signed-out visitors in compatible browsers,
   using a per-site public Web Client ID and the same canonical Broker identity 
   mapping.
 * Automatic background site registration and proof-of-control verification for 
   eligible public HTTPS sites.
 * Encrypted, non-autoloaded per-site broker credentials with exact-origin binding.
 * HMAC-signed server requests with timestamps, fresh nonces and fixed broker paths.
 * Independent, expiring local transactions for concurrent login attempts.
 * Canonical provider identities with conflict-aware account linking and safe unlinking.
 * Adaptive provider controls: one enabled provider uses a full button; multiple
   providers use accessible circular buttons.
 * Shortcodes `[wapu_auth_button]` and `[wapu_auth_login_button]`, plus the `wapu-
   auth/login-button` block.
 * WooCommerce login, registration, checkout return, profile autofill and My Account
   integration.
 * Active WordPress session management, including individual revocation and closing
   other sessions.
 * Safe return URLs, domain rules and a local sandbox allowlist.
 * Local multiprovider analytics for Google, Facebook and traditional WordPress 
   access, with provider filters and sanitized exports.
 * Optional detailed Activity Log, GeoIP enrichment and GA4 event bridge.
 * Identity migration diagnostics, bounded safe backfill and non-destructive broker
   pause/resume controls.
 * Site-scoped support conversations through the broker’s audited HMAC API.
 * Optional private image attachments in Support, capability-gated by the broker
   and proxied without exposing site credentials.
 * Native WordPress login remains available when allowed by the site’s configuration.

#### How Broker Login Works

 1. A visitor selects Google or Facebook.
 2. WordPress validates the return URL and creates an expiring, provider-bound local
    transaction.
 3. WordPress sends a signed request to `/api/v1/google/sessions` or `/api/v1/facebook/
    sessions`.
 4. The broker returns an allowlisted provider start URL and completes provider OAuth.
 5. The broker returns a one-use `wxc_*` code to `/wapu-auth/oauth/callback` on the
    WordPress site.
 6. WordPress consumes the local transaction and exchanges the code at `/api/v1/oauth/
    exchange`.
 7. The plugin requires the returned provider and subject to match the local transaction
    before resolving, linking or creating the WordPress user.
 8. WordPress issues its normal authentication cookies and applies the validated local
    return URL.

#### How Google One Tap Works

 1. When One Tap is enabled, an eligible signed-out HTTPS visitor in a compatible browser
    may receive Google’s native account prompt on the current site. The regular Google
    redirect button remains available when Google does not display the prompt.
 2. WordPress creates a browser-bound local transaction and requests a short-lived 
    One Tap session from the Broker over the existing signed connection.
 3. Google returns an ID-token credential to the page after the visitor selects an 
    account. The browser sends that credential directly to the Broker’s exact, one-
    use, origin-bound endpoint; WordPress never receives it.
 4. The Broker validates Google’s signature plus issuer, audience, authorized party,
    time, verified email and transaction nonce, then issues the same short-lived `wxc_*`
    code used by redirect login.
 5. The browser navigates only to the site’s fixed local callback. The existing canonical
    resolver matches `google/sub`, establishes the WordPress session and returns the
    visitor to the validated same-origin URL.

#### Compatibility and Removed Features

The deprecated `[wapu_auth_popup]`, `[wapu_auth_popup_button]`, `[wapu_auth_login_form]`
and `[wapu_auth_register_form]` aliases render the normal redirect control for compatibility.
They do not open a popup or render a custom form.

Version 2.0 removed the original direct-token One Tap implementation, local modal
authentication, emailed login links, email OTP, trusted-device bypasses and integrated
SMTP configuration. Version 2.1 restores only native Google One Tap through the 
Broker-backed, nonce-bound flow described above. Popup/modal authentication and 
the other retired modules remain removed.

WordPress Multisite is not supported. Activation is stopped before identity migrations
on a network installation.

### Hooks & Filters

#### Actions

 * `wapu_auth_before_login` — before a broker authorization session is created.
 * `wapu_auth_user_authenticated` — after successful user resolution.
 * `wapu_auth_user_created` — after a WordPress user is created.
 * `wapu_auth_provider_account_unlinked` — after one provider mapping is removed.
 * `wapu_auth_google_account_unlinked` — compatibility action after a Google mapping
   is removed.
 * `wapu_auth_analytics_event` — after a local analytics event is recorded.
 * `wapu_auth_log` — after the plugin logger records an entry.
 * `wp_login` — standard WordPress action, fired exactly once for a successful broker
   login.

#### Filters

 * `wapu_auth_user_data` — presentation fields only; provider identity fields remain
   immutable.
 * `wapu_auth_redirect_url` — final redirect, subject to same-origin validation.
 * `wapu_auth_error_message` — local user-facing error copy.
 * `wapu_auth_button_html` — rendered provider control HTML.
 * `wapu_auth_geoip_enabled` — optional GeoIP enrichment.

The legacy `wapu_auth_auth_params`, `wapu_auth_redirect_uri` and `wapu_auth_oauth_base_url`
filters are compatibility notifications. They cannot change the broker host, callback,
provider, state, nonce, signature, ticket or one-use code.

### External Services

#### 1. Wapu Auth Broker (required for social login)

**Fixed origin:** `https://auth.wapuos.com`

**When used:** after activation or update for background registration/verification
and provider health; when a visitor starts or completes social login; when an administrator
deliberately rotates a credential or uses the Support section.

**Endpoints used:**

 * `POST /api/v1/sites/register/init` and `POST /api/v1/sites/register/verify` for
   proof-of-control registration.
 * `GET /health` for a public, secret-free provider and One Tap capability snapshot.
 * `POST /api/v1/google/sessions` or `POST /api/v1/facebook/sessions` to begin login.
 * `POST /api/v1/google/one-tap/sessions` to create a signed, short-lived One Tap
   challenge.
 * Browser `OPTIONS`/`POST` requests to the exact `/api/v1/google/one-tap/credentials/{
   ticket}` endpoint after a visitor selects a Google account.
 * `POST /api/v1/oauth/exchange` to exchange the callback’s one-use code.
 * Browser paths under `/oauth/google/*` or `/oauth/facebook/*` during provider 
   authorization.
 * Site-scoped `/api/v1/support/*` operations only when an administrator uses Support.
 * Signed binary support-image upload plus private thumbnail/content delivery only
   when the broker capability flag is enabled.

**Registration data:** canonical site URL, fixed local callback URL, short-lived
verification URL and registration identifier. The broker performs a public GET of
the verification URL, which returns only the active short-lived challenge.

**Login data:** site ID, HMAC timestamp/nonce/signature headers, provider-bound 
local state, validated return context and the one-use exchange code. With One Tap,
the browser additionally sends Google’s short-lived ID-token credential directly
to an origin-bound Broker endpoint. The credential is validated in memory and is
not stored or returned to WordPress. Sensitive protocol values are not written to
plugin logs.

**Identity data received:** provider, provider subject, email and verification state,
and optional name/avatar fields. Provider tokens, refresh tokens, provider authorization
codes and provider client secrets are not returned to WordPress.

**Support data:** the subject, allowlisted category, public messages and optional
JPEG/PNG/WebP evidence deliberately entered by an administrator. Images are normalized
to remove EXIF/GPS and unnecessary metadata, remain in private broker storage and
are returned only through authorized proxy requests. Internal broker notes and private
agent data are not exposed to WordPress.

**Documents:** [About](https://auth.wapuos.com/about) | [Privacy](https://auth.wapuos.com/privacy)
| [Terms](https://auth.wapuos.com/terms)

#### 2. Google Identity Services / OAuth / OpenID Connect

**When used:** redirect OAuth is contacted after a visitor selects the Google button.
If an administrator enables One Tap and the Broker has not reported the capability
as disabled, the versionless Google Identity Services script at `https://accounts.
google.com/gsi/client` is loaded on eligible signed-out HTTPS pages so Google can
decide whether to display its native prompt.

For redirect login, the visitor reaches Google through the Broker. For One Tap, 
Google returns the selected account’s ID-token credential to the page and the browser
submits it directly to the Broker for nonce-bound verification. Google receives 
normal identity-service and browser/network metadata under its own policies. Provider
access and refresh tokens are not returned to WordPress.

**Policies:** [Google Privacy Policy](https://policies.google.com/privacy) | [Google Terms](https://policies.google.com/terms)

#### 3. Meta / Facebook Login (indirect)

**When used:** only after a visitor actively selects Facebook.

The visitor reaches Facebook through the broker. Meta may receive normal OAuth request
and browser/network metadata under its own policies. Provider tokens stay at the
broker and are not returned to WordPress.

**Policies:** [Meta Privacy Policy](https://www.facebook.com/privacy/policy/) | 
[Meta Terms](https://www.facebook.com/terms/)

#### 4. GeoIP providers (optional, disabled by default)

**Services:** `https://ipapi.co/`, with `https://ipwho.is/` as fallback.

**Data sent:** visitor IP address and normal HTTP metadata.

**When used:** only when the administrator enables GeoIP enrichment. The site owner
is responsible for an appropriate legal basis and consent where required.

**Policies:** [ipapi.co Privacy](https://ipapi.co/privacy/) | [ipwho.is Privacy](https://ipwhois.io/privacy-policy/)

#### 5. Google Analytics 4 event bridge (optional, disabled by default)

The plugin can call a site’s existing `gtag` function with provider-aware social-
login events and limited status metadata. It does not load Google Analytics itself.
The site administrator is responsible for consent and the site’s Analytics configuration.

### Privacy & Data Retention

Wapu Auth stores local configuration, the optional public One Tap Client ID, encrypted
broker credentials, a one-way verified-origin fingerprint, hashed and expiring transaction
state, canonical provider mappings, compatibility metadata, WordPress session data
and any enabled analytics or Activity Log records. Depending on settings, detailed
logs can contain account email, IP address and derived location.

The automatic-connection state contains only sanitized status codes, counters, timestamps,
provider availability and a one-way origin hash. It never contains the broker challenge,
registration ID, site secret, signature, request payload or remote response.

While one proof-of-control operation is pending, its registration ID and challenge
are held separately in a short-lived WordPress transient only until verification,
explicit recovery or expiry; they are not copied to plugin logs.

Wapu Auth does not store provider access tokens, provider refresh tokens, provider
authorization codes, Google One Tap ID-token credentials, raw HMAC signatures, clear
Broker tickets or one-use exchange codes. One Tap ticket and nonce hashes expire
at the Broker and are deleted after use or pruning. Legacy Google Client ID/Secret
values from 1.x are retained only in separate authenticated encrypted storage until
an administrator completes the protected removal flow; only a valid public Client
ID may be copied automatically into the active One Tap setting.

Optional GeoIP and GA4 features are disabled by default. Administrators should update
their own privacy notice and select a retention period appropriate to their jurisdiction.

Optional Support images are disabled until the broker advertises the compatible `
WAPU-SUPPORT-ATTACHMENT-V1` capability. Pending images are temporary and pruned 
after expiry; linked images are retained only for the broker support workflow and
removed under its ticket/site retention policy. They are not attached to WhatsApp
or administrative email notifications. The broker strips EXIF, GPS and unnecessary
image metadata during normalization. Site administrators should avoid uploading 
secrets or unrelated personal information and describe this support processing in
their own privacy notice when the feature is enabled.

## Скриншоты

[⌊Wapu Auth dashboard — connection status, canonical identities, active sessions,
alerts and recent sign-in activity.⌉⌊Wapu Auth dashboard — connection status, canonical
identities, active sessions, alerts and recent sign-in activity.⌉[

**Wapu Auth dashboard** — connection status, canonical identities, active sessions,
alerts and recent sign-in activity.

[⌊Social access overview — Google and Facebook provider controls, live button preview
and WordPress and WooCommerce integrations.⌉⌊Social access overview — Google and
Facebook provider controls, live button preview and WordPress and WooCommerce integrations
.⌉[

**Social access overview** — Google and Facebook provider controls, live button 
preview and WordPress and WooCommerce integrations.

[⌊Store login experience — Google social access alongside the site's standard customer
authentication.⌉⌊Store login experience — Google social access alongside the site's
standard customer authentication.⌉[

**Store login experience** — Google social access alongside the site’s standard 
customer authentication.

[⌊WooCommerce integration — login, registration and checkout placement, customer
prefill and connected-account controls.⌉⌊WooCommerce integration — login, registration
and checkout placement, customer prefill and connected-account controls.⌉[

**WooCommerce integration** — login, registration and checkout placement, customer
prefill and connected-account controls.

[⌊Wapu Auth Broker connection — automatic connection, exact-origin status, provider
health and signed HMAC diagnostics.⌉⌊Wapu Auth Broker connection — automatic connection,
exact-origin status, provider health and signed HMAC diagnostics.⌉[

**Wapu Auth Broker connection** — automatic connection, exact-origin status, provider
health and signed HMAC diagnostics.

## Блоки

Этот плагин предоставляет 1 блок.

 *   Wapu Auth Add accessible Google and Facebook login controls powered by Wapu
   Auth Broker.

## Установка

#### Automatic Installation

 1. In WordPress, open **Plugins > Add New** and search for **Wapu Auth – Social Login
    for WordPress and WooCommerce**.
 2. Install and activate the plugin.
 3. Keep WordPress cron enabled and allow outbound HTTPS requests to `https://auth.
    wapuos.com`.
 4. Ensure the site’s canonical URL and REST API are publicly reachable over HTTPS 
    without Basic Auth, maintenance HTML or a redirect between apex and `www`.
 5. Open **Wapu Auth > Connection** to monitor the background state. No normal registration
    or verification click is required.
 6. Configure enabled providers, appearance, local access rules and WooCommerce placement.
    To enable optional One Tap, add this site’s public Google Web Client ID under **
    Wapu Auth > Providers**; no Client Secret is requested.
 7. Validate Google, Facebook and traditional login end to end on staging before production
    rollout.

#### Manual Installation

 1. Upload the release ZIP through **Plugins > Add New > Upload Plugin**, or extract
    the `wapu-auth-social-login` directory into `/wp-content/plugins/`.
 2. Activate **Wapu Auth – Social Login for WordPress and WooCommerce**.
 3. Follow the automatic-connection and staging-validation steps above.

#### Updating from 1.x or a prerelease

 1. Back up the database and test the update on staging first.
 2. The versioned upgrade creates or verifies plugin-owned identity and transaction
    tables, preserves users and commerce records, and retains legacy Google credentials
    in encrypted non-autoloaded storage.
 3. If a valid Google Client ID was retained from 1.x, version 2.1 copies only that
    public ID into the new non-autoloaded One Tap setting automatically. A direct 1.
    x upgrade also preserves the previous enabled state when its former scope already
    covered guest pages; a login-pages-only setup and sites that already passed through
    2.x remain disabled until an administrator reviews and enables One Tap.
 4. The asynchronous worker analyzes legacy identity metadata and backfills only unambiguous
    mappings for the same WordPress user ID.
 5. Critical conflicts leave broker login paused for review; no accounts are merged
    automatically.
 6. A verified credential for the current origin is reused. The updater does not rotate
    it or create another broker registration.
 7. A database clone whose credential is bound to another origin remains blocked until
    an administrator deliberately resolves the environment.

## Часто задаваемые вопросы

### Do I enter Google or Facebook client credentials in WordPress?

Redirect-based Google and Facebook login still requires no provider credentials 
in WordPress. Optional native Google One Tap requires only the site’s public Google
OAuth **Web application Client ID**, because Google requires the storefront’s exact
Authorized JavaScript Origin. Wapu Auth never asks for a Client Secret for One Tap.

### How do I configure Google One Tap?

Open **Wapu Auth > Providers > Google One Tap** and select **How to get the Client
ID**. Complete the project’s Branding and Audience configuration, then create a **
Web application** client. The modal shows the exact HTTPS origin to add under **
Authorized JavaScript origins** and links directly to Google Auth Platform. Paste
the resulting Web Client ID and enable One Tap. Do not add a Client Secret or an
Authorized Redirect URI for this flow. Google changes can take a few minutes; an`
origin_mismatch` error normally means the configured scheme, host, or port is not
an exact match. If the site uses full-page or CDN caching, purge that cache after
first enabling or disabling One Tap so every cached page has the current script 
set. Client ID changes are additionally bound to the current server-created session,
preventing stale HTML from selecting an outdated audience.

### What if a security policy blocks One Tap?

Keep the site’s Content Security Policy compatible with Google Identity Services
and the Broker. At minimum, allow the versionless script `https://accounts.google.
com/gsi/client`, the Google Identity Services resources under `https://accounts.
google.com/gsi/`, and browser connections to `https://auth.wapuos.com`. A stricter
policy may require matching `script-src`, `frame-src` and `connect-src` entries.
The normal Google redirect button remains the fallback if the prompt is blocked 
or unavailable.

### Why is the automatic connection waiting or blocked?

The normal causes are a non-public or non-HTTPS URL, localhost or a reserved hostname,
Basic Auth, maintenance mode, a firewall blocking the verification endpoint, disabled
WP-Cron, outbound HTTPS restrictions, DNS mismatch, or a cloned database carrying
credentials for another origin. Correct the environment and use **Retry automatic
connection**. Do not paste broker secrets into support requests.

### Will an update rotate or duplicate an existing broker credential?

No. A verified credential bound to the current origin short-circuits registration.
Pending proof-of-control work is reused under a lock. An ambiguous one-time verification
response stops for explicit recovery instead of starting a replacement automatically.

### Does the local HMAC diagnostic prove the remote credential is active?

No. It proves that WordPress can decrypt the local secret and build a valid signature.
The current broker contract has no authenticated credential-health endpoint. Provider
availability and an end-to-end staging login remain separate checks.

### Can one WordPress account link both providers?

Yes. Canonical mappings are provider-specific and enforce one subject per provider
and one provider identity per WordPress user. Cross-provider linking requires an
authenticated user and a fresh broker flow.

### What happens when Facebook does not return an email address?

Wapu Auth follows the broker’s nullable Facebook-email contract. It does not invent
or silently trust an email. The account-linking flow must resolve safely under the
configured local policy.

### Does Wapu Auth replace the normal WordPress login?

No. Native WordPress and WooCommerce login remain available. Pausing broker mode
stops only new social-login starts.

### Does WooCommerce have to be active?

No. Wapu Auth works with WordPress alone. WooCommerce hooks and My Account features
are loaded only when WooCommerce is active.

### Can customers manage sessions and connected providers?

Yes. When enabled, WooCommerce My Account shows active sessions and connected-account
controls. Unlinking a provider does not delete the WordPress account or orders.

### How do I remove plugin data?

The Security settings contain the uninstall-retention choice. If deletion is enabled
before uninstall, operational settings, canonical mappings, local transactions, 
analytics and logs are removed. WordPress users, WooCommerce orders and unrelated
data are not deleted. Retained legacy Google credentials have a separate protected
irreversible-removal action.

### Does an automated test prove live provider login works?

No. Automated tests mock broker and provider transport. Complete a real fresh-install
and legacy-update validation on staging, including Google, Facebook, relink, unlink,
traditional login and WooCommerce return flows.

### What happens to images attached to a support conversation?

Support images are optional and appear only when Wapu Auth Broker advertises the
compatible signed-upload capability. The initial formats are JPEG, PNG and WebP,
with up to four images, 5 MB per image and 15 MB per message. WordPress validates
the file before forwarding its exact bytes through a server-to-server signed request;
the browser never receives the site secret or an HMAC signature.

The broker decodes and re-encodes accepted images, removes EXIF/GPS and unnecessary
metadata, creates a private thumbnail and stores both files outside public web storage.
Images are served back through an administrator-authorized WordPress REST proxy 
with private no-store responses. Pending uploads expire and are pruned; linked files
follow the broker’s support-ticket retention and deletion policy. Share only evidence
needed to resolve the issue and avoid passwords, payment data or sensitive personal
information.

### Where are the service documents?

 * [About Wapu Auth Broker](https://auth.wapuos.com/about)
 * [Privacy Policy](https://auth.wapuos.com/privacy)
 * [Terms of Service](https://auth.wapuos.com/terms)

## Отзывы

Нет отзывов об этом плагине.

## Участники и разработчики

«Wapu Auth – Social Login for WordPress and WooCommerce» — проект с открытым исходным
кодом. В развитие плагина внесли свой вклад следующие участники:

Участники

 *   [ Victor Flores ](https://profiles.wordpress.org/victor88lm/)

«Wapu Auth – Social Login for WordPress and WooCommerce» переведён на 1 язык. Благодарим
[переводчиков](https://translate.wordpress.org/projects/wp-plugins/wapu-auth-social-login/contributors)
за их работу.

[Перевести «Wapu Auth – Social Login for WordPress and WooCommerce» на ваш язык.](https://translate.wordpress.org/projects/wp-plugins/wapu-auth-social-login)

### Заинтересованы в разработке?

[Посмотрите код](https://plugins.trac.wordpress.org/browser/wapu-auth-social-login/),
проверьте [SVN репозиторий](https://plugins.svn.wordpress.org/wapu-auth-social-login/),
или подпишитесь на [журнал разработки](https://plugins.trac.wordpress.org/log/wapu-auth-social-login/)
по [RSS](https://plugins.trac.wordpress.org/log/wapu-auth-social-login/?limit=100&mode=stop_on_copy&format=rss).

## Журнал изменений

#### 2.1.0

 * Restored native Google One Tap/FedCM for signed-out HTTPS visitors in compatible
   browsers without an external-page authentication redirect.
 * Added a signed Broker One Tap session, exact-origin CORS endpoint, one-use ticket,
   OIDC nonce, Google ID-token verification and reuse of the existing `wxc_*` exchange/
   canonical identity flow.
 * Added automatic, idempotent reuse of only a valid public Google Client ID retained
   from 1.x; Client Secrets are never copied into One Tap or shown in its interface.
 * Added a Providers setting with server-side validation, exact Authorized JavaScript
   Origin, setup status and an accessible Google Auth Platform instructions modal.
 * Kept One Tap disabled on fresh and already-upgraded 2.x installations until an
   administrator supplies or confirms the Client ID and enables it. Direct 1.x upgrades
   preserve the former enabled state only when the recovered ID is valid, the site
   uses HTTPS and the former scope is exactly `all` or `guest`; login-only, malformed
   and unknown scopes remain disabled for review.
 * Added fail-closed origin, callback, provider, audience, nonce, expiry, replay,
   browser-binding, capability and rate-limit checks while retaining the normal 
   Google redirect button as fallback.
 * Bound GIS initialization to the Client ID returned by the current server-created
   session so stale cached HTML cannot submit a credential for an outdated audience.
 * Corrected the administration source interface to English and refreshed the complete
   Spanish translation catalog.
 * Removed the custom login and registration form editor, renderers and frontend
   assets. Historical form shortcodes remain compatibility aliases for the standard
   social-login button.
 * Removed the optional custom styling override for WooCommerce My Account; the 
   page now keeps the active theme and WooCommerce styles.
 * Changed the sidebar lockup to sit centred on desktop, where the drawer close 
   button is hidden and there is nothing to balance it against. The mobile drawer
   and bar keep the logo left-aligned next to their buttons.
 * Added the Wapu Auth wordmark to the admin sidebar and mobile bar as an AVIF with
   transparency, replacing the placeholder mark and text lockup. The brand slot 
   still falls back to the text lockup when the asset is absent, so nothing breaks
   if the file is removed.
 * Removed the multi-provider preview section from Login and appearance. It duplicated
   what the main preview already shows and never earned its space.
 * Removed the stylesheet rules and the browser code that only existed to drive 
   it, including the hover handlers and the circle/icon sizing pass that ran on 
   every control change.
 * Note: the multi-provider icon controls (circle size, icon size, spacing, shadow,
   colours) still save and still apply on the front end, but they no longer have
   a live preview in the admin.
 * Fixed the multi-provider preview rendering its captions detached from the previews
   they describe. The four captions and four preview boxes were flat siblings, so
   the grid placed each in its own cell; each case is now a single figure holding
   its own caption and framed preview, with the footnote spanning the row.
 * Changed the appearance panel to wider columns so control labels stop clipping,
   and made the text-and-switches row wrap instead of overflowing.
 * Removed the per-provider «Diagnostics» button and the card footer that held it.
   The button existed to surface missing local secret keys, which the broker now
   owns entirely, so it no longer had anything to report.
 * Removed the stylesheet rules left behind by the deleted provider footer and metric
   tiles, and corrected the provider card to a two-row grid.
 * Removed the per-provider metric tiles and the «no local credentials» note from
   Providers; credentials are the broker’s concern, so the card now carries identity
   and local visibility only. The metrics were the sole consumer of a per-provider
   COUNT query and an activity-stats lookup, both of which are gone with them.
 * Removed the coloured top rule from the provider cards.
 * Changed Login and appearance into a real customization panel: the two stacked
   columns were flattened into one grid, the preview leads as a full-width band,
   and the remaining control groups flow into columns. Nothing is pinned on scroll
   anymore.
 * Changed the Analytics metric row to six uniform tiles on a single line with proper
   padding and sentence-case labels. The decorative icon is dropped in this variant
   because two of the six never had one, which is what caused the 4 + 2 wrap and
   the cramped text.
 * Changed the provider comparison list to use dividers and breathing room instead
   of tightly packed rows.
 * Changed WooCommerce from seven stacked cards (four of them holding a single toggle)
   to two grouped cards in a responsive grid: button placement together with position
   and separator, and account experience together with My Account style, avatar 
   and connected accounts.
 * Changed stacked toggles into a real settings list — label and description on 
   the left, control on the right, hairline dividers — instead of a column of padded
   bubbles.
 * Changed Login and appearance into an editor layout: the preview pins while the
   controls scroll, and control groups flow in columns instead of one field per 
   row.
 * Changed the provider cards to a compact density: smaller identity block, tighter
   padding and metrics rendered as a single strip instead of three boxed tiles.
 * Changed the Connection screen to two balanced columns so the reference cards 
   stop stretching the page.
 * Removed the «Monitor local activity» banner from Summary; when nothing is actually
   pending the summary now shows no recommended action at all.
 * Fixed the activity chart on Analytics not responding to hover: it now uses index-
   based interaction with a styled tooltip, so pointing anywhere on a day reveals
   every series instead of requiring an exact hit on a 2px dot.
 * Fixed the migration metrics rendering as unstyled stacked text. The markup referenced`
   wapu-auth-ui-metrics` / `wapu-auth-ui-metric`, which no stylesheet defined; both
   are now real metric tiles.
 * Added a skeleton loading state for charts, plus reusable skeleton primitives,
   with a guard so a missing Chart.js never strands the placeholder on screen.
 * Added an explicit empty state to charts when every series is zero, instead of
   drawing a dead flat line.
 * Changed Conflicts to show per-status finding counts that double as one-click 
   filters, and to distinguish «the analysis found nothing» from «nothing matches
   these filters».
 * Changed the Summary layout: the recommended action is now a compact banner instead
   of a half-empty card, resting states are single lines, and the blue accent rule
   was removed from cards.
 * Changed Tools to lead with the actionable endpoints and shortcodes, collapsing
   the long-form reference into disclosures.
 * Changed the admin brand lockup to use `assets/images/wapu-auth-logo.svg` (or `.
   png` / `.webp`) when present, falling back to the text lockup otherwise.
 * Changed the migration activation path to a tighter step rhythm to reduce page
   scroll.
 * Changed the administration interface to a neutral white, blue and gray design
   system: one blue accent replaces the previous magenta/yellow brand colors, and
   every surface, badge, alert and chart color now resolves from the shared design
   tokens.
 * Changed shape, spacing and elevation across the console to softer radii, wider
   padding and low-contrast shadows, combining iOS refinement with Material Design
   3 proportions.
 * Changed buttons, inputs, switches, tabs, tables and dialogs into a single reusable
   component vocabulary with larger touch targets, a calmer focus ring and subtle
   state transitions.
 * Changed the analytics charts to the same palette, so series stay distinguishable
   by lightness and remain readable in grayscale.
 * Kept authentication flows, integrations, settings, endpoints and stored data 
   unchanged throughout the administration visual redesign.
 * Fixed WooCommerce customer getter autofill leaking the authenticated Google user’s
   first or last name into a different customer inspected by POS or admin code. 
   Autofill now applies only when the WC_Customer ID matches the authenticated user.
 * Added an isolated regression fixture for current, different, guest, existing-
   value, non-Google and logged-out customer contexts.
 * Fixed a dead end after a failed provider sign-in: the visitor now returns to 
   the screen that started the attempt instead of the site home, so alternative 
   sign-in methods stay one click away. An explicit error URL configured by the 
   administrator still wins.
 * Added the `wapu_auth_render_error_notice` filter and the public `Assets::get_error_message()`
   helper so a theme can place the same error copy next to its own form instead 
   of the footer notice.

#### 2.0.0

 * Added stable Google and Facebook login through the fixed Wapu Auth Broker.
 * Added asynchronous connection on activation and update, with cron, admin fallback,
   expiring lock, bounded retries and manual recovery.
 * Added verified-origin and cloned-environment protection; verified current-origin
   credentials are never re-registered or auto-rotated.
 * Added encrypted non-autoloaded broker credential storage and local HMAC signing
   diagnostics.
 * Added canonical multiprovider identities, provider-bound transactions and conflict-
   aware upgrade preflight.
 * Added bounded safe backfill that preserves the same WordPress user IDs and never
   merges critical conflicts automatically.
 * Added Google, Facebook and traditional analytics, provider activity/error metrics,
   provider filters and sanitized exports.
 * Added adaptive provider buttons across shortcodes, the block, custom forms and
   WooCommerce.
 * Added provider availability, local ordering and responsive provider administration.
 * Added Active Sessions, account linking/unlinking, WooCommerce return handling
   and optional profile autofill.
 * Updated the public Wapu Auth name to reflect Google and Facebook social login
   for WordPress and WooCommerce.
 * Added a responsive administration console, identity migration review and site-
   scoped broker Support.
 * Added capability-gated private JPEG/PNG/WebP attachments, signed binary upload,
   thumbnail proxy, previews and an accessible lightbox in Support.
 * Preserved native WordPress users, roles, sessions and WooCommerce customer/order
   ownership during the versioned upgrade.
 * Preserved legacy Google credentials in encrypted non-autoloaded recovery storage
   until a separately authorized purge.
 * Removed Google One Tap, popup/modal authentication, email login links, email 
   OTP, trusted-device bypasses and integrated SMTP settings.
 * Security: fixed-origin HTTPS transport, no redirects, bounded responses, HMAC
   timestamps/nonces and strict callback/provider matching.
 * Compatibility: deprecated popup-named shortcodes render the normal redirect control
   for one cycle.
 * Compatibility: WordPress single-site 6.3+ and PHP 8.0+; Multisite remains fail-
   closed and unsupported.
 * Validation note: broker/provider transport is mocked in automated tests; real
   fresh-install and legacy-update staging checks remain required before production
   rollout.

#### 1.1.0

 * Added Active Sessions and smart WooCommerce redirects.
 * Added experimental authentication and mail-delivery features retired by 2.0.0.

#### 1.0.0

 * Initial Google login release with button customization, analytics, domain restrictions,
   sandbox, forms, WooCommerce integration and shortcodes.

## Мета

 *  Версия **2.1.0**
 *  Обновление: **2 месяца назад**
 *  Активных установок: **70+**
 *  Версия WordPress ** 6.3 или выше **
 *  Совместим вплоть до: **6.9.9**
 *  Версия PHP ** 8.0 или выше **
 *  Языки
 * [English (US)](https://wordpress.org/plugins/wapu-auth-social-login/) и [Spanish (Mexico)](https://es-mx.wordpress.org/plugins/wapu-auth-social-login/).
 *  [Перевести на ваш язык](https://translate.wordpress.org/projects/wp-plugins/wapu-auth-social-login)
 * Метки:
 * [Facebook login](https://ru.wordpress.org/plugins/tags/facebook-login/)[oauth2](https://ru.wordpress.org/plugins/tags/oauth2/)
   [passwordless login](https://ru.wordpress.org/plugins/tags/passwordless-login/)
   [social login](https://ru.wordpress.org/plugins/tags/social-login/)[woocommerce login](https://ru.wordpress.org/plugins/tags/woocommerce-login/)
 *  [Дополнительно](https://ru.wordpress.org/plugins/wapu-auth-social-login/advanced/)

## Оценки

Пока что нет ни одного отзыва.

[Ваш отзыв](https://wordpress.org/support/plugin/wapu-auth-social-login/reviews/#new-post)

[Посмотреть всеотзывы](https://wordpress.org/support/plugin/wapu-auth-social-login/reviews/)

## Участники

 *   [ Victor Flores ](https://profiles.wordpress.org/victor88lm/)

## Поддержка

Решено проблем за последние 2 месяца:

     1 из 1

 [Перейти в форум поддержки](https://wordpress.org/support/plugin/wapu-auth-social-login/)