Download the PHP package ninjaportal/portal-api without Composer

On this page you can find all versions of the php package ninjaportal/portal-api. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of ninjaportal/portal-api

Informations about the package portal-api

NinjaPortal API Package

REST API package for NinjaPortal (ninjaportal/portal) with:

Routes

Configuration Highlights

Main config: config/portal-api.php

Important keys:

Out of the box, portal-api ships JWT-ready auth models:

When the shared ninjaportal.models.User / ninjaportal.models.Admin config values are still pointing at the core Portal models, portal-api promotes them to these API models automatically so the Portal repositories and API auth layer resolve the same classes. If your application already overrides those model config values, portal-api leaves them untouched.

Extensibility (Client Customization)

1) Custom User/Admin Models

The package supports overriding the consumer/admin auth models via config:

The API package now resolves model classes and table names through NinjaPortal\Api\Support\PortalApiContext, which is used by:

2) Authentication Plugins (MFA / SSO)

Auth controllers now depend on NinjaPortal\Api\Contracts\Auth\AuthFlowInterface instead of directly implementing login logic.

Default implementation:

Token lifecycle is abstracted by:

This makes it easier for a separate package to:

3) Auth Lifecycle Events (for plugins)

Events emitted by the API package:

Suggested MFA package approach:

  1. Bind your own AuthFlowInterface implementation.
  2. Reuse TokenServiceInterface after challenge success.
  3. Optionally listen to auth events for auditing / throttling / risk scoring.

4) Authorization Strategy Replacement

Admin controllers can optionally perform policy checks through:

Disable policy checks (keep route RBAC only):

Replace the authorizer in another package/service provider if you need:

RBAC vs Policy Checks

Two layers can coexist:

Recommended for standalone portal deployments:

Pagination / List Endpoint Conventions

Shared helpers live in:

Preferred list pattern:

  1. Use listParams() for per_page, order_by, direction
  2. Query/paginate in service or query builder
  3. Return via respondPaginated()

Intentionally Unpaginated Endpoints (Current Design)

These are intentionally returned as full collections because they are typically small/config-like datasets:

If a client deployment grows these significantly, convert them to the standard paginated pattern.

Refresh Token Pruning

Refresh tokens are stored in portal_api_refresh_tokens.

Prune expired/revoked rows manually:

Queue prune job instead:

Optional scheduler integration (package-level):

Docs (Scribe)

Development (Package-local)

Available scripts:

Note:

All versions of portal-api with dependencies

PHP Build Version
Package Version
Requires php Version ^8.2
spatie/laravel-package-tools Version ^1.16
spatie/laravel-permission Version ^6.0
php-open-source-saver/jwt-auth Version ^2.8
illuminate/contracts Version ^11.0||^12.0
illuminate/support Version ^11.0||^12.0
ninjaportal/portal Version ^0.1
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package ninjaportal/portal-api contains the following files

Loading the files please wait ...