AjPlus Captcha for Java Backends and Cross-Platform Apps

What AjPlus Captcha Solves

AjPlus Captcha addresses application access checks where a backend needs to distinguish a human action from a direct or invalid request. The repository describes two challenge types, `blockPuzzle` and `clickWord`. A user either drags a block into the correct position or clicks the requested characters, and the backend verifies that action through the captcha service. This is aimed at Java applications that need a verification component across web, mobile, and cross-platform clients. The repository also presents the problem as preventing invalid access, including a request that calls the protected service without completing the CAPTCHA interaction.

The project is not limited to a browser page. Its design lists support for Android, iOS, Flutter, uni-app, React Native, Vue, Angular, HTML, and PHP. The Java side is important because verification is described as a backend call to `captchaService.verification`. A frontend can display the challenge, but the server must establish whether the submitted result is acceptable. That separation makes the toolkit relevant to teams with a Java service and more than one client target. It also means that copying only a UI component is not equivalent to integrating the full verification flow.

The README describes the tool as an open source toolset and says the core source has no dependency library, making it easier to include in a backend service. It also states that the core API is simple and that instances are initialized through Java SPI. Those claims describe an extension-oriented Java design, but the repository does not document production configuration, storage behavior, image delivery, or failure handling in detail.

AjPlus Captcha's Request and Verification Flow

The documented interaction has two named stages: `Check` and `Verify`. During `Check`, the user performs an action, such as dragging a puzzle block or clicking words. The frontend presents the challenge and collects that action. During `Verify`, the backend service binds the user action to its service and calls `captchaService.verification` to determine whether the request should be allowed.

The repository includes a sequence diagram link under the integration section, but the README text does not reproduce its fields or endpoints. That omission matters for an engineer choosing this project. A client integration cannot be implemented accurately from the README alone if the exact request payload, response fields, token handling, and server-side route are required. The documentation gives the conceptual sequence, not a complete protocol reference.

The source layout separates `core/`, `service/`, and `view/`. The core is the Java-side library, the service contains a Spring Boot application, and the view contains frontend examples, including `view/vue`. The repository also includes `index.php`, which indicates a PHP-facing example or entry point, but the README does not explain how that file is deployed. The architecture is therefore visible from the directory layout, while operational details remain undocumented in the repository text.

Running the Spring Boot Service and Vue Example

The README gives a development workflow rather than a packaged installation procedure. For the backend, import the source code into Eclipse or IntelliJ and start `StartApplication` in the `service.springboot` package. The README links separately to the online images, but it does not give a shell command for downloading them or state where they must be placed. A developer should therefore expect to inspect the source layout and image references before running the service.

For the Vue frontend, open the files under `view/vue` in Visual Code, as the README calls it, then run the documented commands. The expected development result includes the application URL shown in the README.

npm install
npm run dev

The README shows a successful local development message and identifies `http://localhost:8081` as the application address. This is a local frontend workflow. It does not document production build commands, environment variables, backend host configuration, or the command used to package the Java service. The repository's `pom.xml` indicates a Maven-based Java build, but the README does not provide an exact invocation, so no build command is supplied here.

The two modes also make a clear dependency on the image assets. The README points to `https://gitee.com/anji-plus/AJ-Captcha-Images` for online images, while the repository contains an `images/` directory. It does not explain whether the service reads local files, remote URLs, or another configured source. That gap should be resolved before relying on a deployment.

SPI Extension Support and Platform Coverage

AjPlus Captcha's most notable design choice is its use of Java SPI for instance initialization. The README says that all instances are initialized by Java SPI and that custom implementations can be added to form a new CAPTCHA type. This is a concrete extension point for teams that need to change challenge behavior without replacing the entire integration. However, the repository text does not provide a service-provider file example, interface definition, registration procedure, or sample custom implementation, so the documented claim cannot be turned into an implementation recipe from this README alone.

The platform list is broad, but support should be understood as a repository claim rather than a guarantee of identical feature depth everywhere. The project names Android, iOS, Flutter, uni-app, React Native, Vue, Angular, HTML, and PHP, and the README explicitly says it integrates with those clients. It does not document version compatibility for each SDK, package names, platform-specific setup, or whether every platform supports both `blockPuzzle` and `clickWord`. The source tree shown in the repository includes a Vue example, but the README does not enumerate all client example directories.

This distinction is important for adoption. A team targeting Flutter or uni-app may find the named support useful, yet it still needs to inspect the corresponding source files and confirm how it communicates with the Java service. The project is strongest as a self-hosted Java component with client examples, not as a documented universal SDK catalog.

Operational Limits and Failure Cases

The clearest limitation is incomplete operational documentation. The README does not document database use, session or token storage, rate limiting, retry behavior, challenge expiry, image failure handling, or what happens when a user reloads during verification. It also does not specify the backend endpoint contract. These omissions make it difficult to assess production behavior without reading the source.

A second constraint is the image dependency. The README distinguishes the challenge UI from the online image resource and provides an external image repository link. If an internet-facing deployment cannot reach the expected image source, the challenge presentation may fail unless the assets are configured or hosted through a supported mechanism. The repository text does not confirm that local image hosting is supported, so that should not be assumed.

AjPlus Captcha may also be the wrong choice when a deployment needs a managed CAPTCHA service, a documented protocol, or an independently maintained client package. It is intended for teams willing to run and inspect the Java service themselves. It is not a substitute for a design review of accessibility, abuse resistance, privacy, or operational monitoring. The README mentions a security feature, but it does not define that feature or provide an assessment method, so it cannot be used as evidence of a particular security guarantee.

Compared with a Conventional Image CAPTCHA

A conventional image CAPTCHA commonly asks the user to recognize distorted characters from an image. AjPlus Captcha uses a different interaction model: a user completes a sliding block puzzle or a click-word task. That changes the required frontend interaction and makes mobile gestures and cross-platform UI examples more relevant than a plain text-entry component.

The backend model also differs from a simple client-side image. AjPlus Captcha documents a `Verify` stage in which the backend calls `captchaService.verification`, so the protected service is expected to validate the result rather than trusting the widget alone. This is a meaningful architectural difference. The trade-off is responsibility: a self-hosted Java service gives teams control over integration and extension, but the README leaves deployment, storage, expiration, and error behavior to the implementation.

For a team that only needs a conventional text-entry CAPTCHA and already has a standard provider, AjPlus Captcha introduces a different UI and backend protocol to learn. For a team already committed to Java and interested in puzzle or click-word challenges, the two documented CAPTCHA types provide a more specific fit than a generic character image.

Maintenance, Releases, and License

The repository is not archived, and its last push was on 2026-10-09. That indicates recent repository activity, but the README does not describe a release cadence, compatibility policy, migration guide, or supported Java version. GitHub releases are absent from the repository information, so there is no release note from which to derive upgrade behavior. The README's work plan points to Gitee issues, which gives the project an issue location but does not establish response or maintenance commitments.

The project uses the Apache-2.0 license. That identifies the stated licensing terms for the repository, but it is not legal advice and the README does not describe contributor licensing, third-party image rights, or obligations for hosted deployments. Teams should review the `LICENSE` file and the terms associated with any external image resources separately.

Because there are no documented GitHub releases, upgrade planning cannot rely on a published release stream in the repository. The Java SPI extension point can also affect upgrades because custom implementations may need to track changes in core interfaces and initialization behavior. The repository does not document that compatibility boundary.

Editorial conclusion

Adopt AjPlus Captcha when a Java service needs a self-contained sliding puzzle or click-word verification flow and the team can review the frontend and backend integration directly. Do not adopt it without checking the server-side verification path, client coverage for your exact platform, image hosting requirements, and your own compliance needs. The repository has no GitHub releases, so its upgrade process is not documented there; the last push was on 2026-10-09.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. raodv/captcha on GitHub
5. README