ApiOpenStudio Admin production docker fixed

While preparing for yesterday’s seminar, it was found that the naala89/apiopenstudio_admin docker images were broken (the issue can be viewed here).

The good old fashioned “it works on my machine” came back to bite us, but the code has been updated and it is now loomed correctly into the GitLab pipelines. Many thanks to laughing_man77 for jumping on this so quickly!

Problem solved!

We’re pleased to announce that the issue has been resolved, and all tags have been re-uploaded to docker hub. So that was a really quick turn-around of 1 day (and we even had a chance to sleep on it before pushing it live).

Note: the only code that was affected was the https://gitlab.com/apiopenstudio/docker_images/apiopenstudio_admin_docker_prod repository. So if you have an existing checkout of the admin MVP code, this will not affect you.

Apart from the good news that full production images for ApiOpenStudio core and admin are fully working and tested, I also tested the released image on an existing server – and proved that the install time of admin is under 5 minutes!

Beta release is here!!!

We are excited to announce the official release of the Beta Version of ApiOpenStudio!

We have worked very hard on this release, and the release includes a lot of bug-fixes, enhancements and requested features. Here is a quick overview up the updates:

Beta release features

  • Updated the wiki:
  • Fixed issues in https://phpdoc.apiopenstudio.com.
  • Fixed caching:
    • Caching supports single and cluster cache servers, or on-server caching.
    • Added support for Redis.
    • Deprecated support for APC.
    • Implemented optional caching for individual processors.
  • Remote server and email outputs via plugins.
  • Created multiple plugins for remote output, see https://packagist.org/packages/apiopenstudio
  • Automated OpenApi document generation, supporting 1.x, 2.x, 3.x.
  • Ability to manage 3rd party packages and repositories within ApiOpenStudio.
  • Created two sample processor plugins
  • Implemented Fragments (process repeated calculations only once).
  • Added new processors to core:
    • JsonPath & XmlPath.
    • Cast.
    • Logic processors:
      • Do…While.
      • For…Each.
      • If…Then…Else.
      • Sequential.
    • Math.
    • Modules CRUD.
    • OpenApi CRUD.
  • Added more unit tests (all core functionality is now fully tested).
  • Added command line scripts (and API – so that it can be done using the GUI) to manage plugins.
  • Integrated the ApiOpenStudio CLI commands (install, update, module) with Composer.
  • Added a new page to the admin GUI to manage plugins.

We still have some known issues, and features that we want to build:

Tasks in the immediate roadmap

  • Begin the re-design and rebuild for the admin GUI with better UX and UI. This will include a drag ‘n’ drop interface to building resources.
  • Create a production docker for easier and secure installation.
  • Fix minor issues in the automated OpenAPI document generation
  • Add scanning for GET and POST variables to be automatically added to the OpenAPI documentation.
  • Mechanisms to upgrade or downgrade OpenAPI versions.
  • A mechanism to update OpenAPI if the domain is changed.
  • Add testing for PHP 8.1.
  • Add groups to permissions.

Increased security and speed with JWT tokens

Current dev work is almost complete for implementing authorisation with JWT token for all resources! This will be part of the upcoming Beta release.

The ticket can be viewed in Gitlab.

This will replace the existing alpha version of a custom token and token TTL for each user in the user table.

It is quite important to note, before we move on, that JWT tokens are a different thing to oauth2, implicit grant, explicit grant, application grant and PKSE authorisation flow. JWT is only a standard for tokens. If you need to implement oauth2 or other similar workflows this is separate from the JWT implementation.

The problem

The problem with the former approach, was that resource requests had to make DB calls to the user, user_roles, roles, account and application tables in order to verify user permissions to that particular resource, FOR EVERY API CALL. This obviously negatively impacted performance for API calls.

This also meant that authorisation was not easily scalable to authorisation servers for enterprise implementation, because the implementation of the token and authorisation for API calls was tightly coupled to the ApiOpenStudio database and several of its tables.

The solution

Although the former approach was stateful (it maintained login state, so users could login and out), the stateless JWT token approach means that the token does not need to be stored in the database. The downside of stateless JWT tokens, is that there is no logout state. So if a user’s access is revoked, they will still have access to resources until their current token goes stale.

However, this can be mitigated by making the JWT token lifetime short in the ApiOpenStudio configuration.

Each JWT token contains custom claims for user ID and all roles that that user has. So when the initial request is received by ApiOpenStudio, it just decrypts the token and validates the user’s roles against the resources account/application and permissible user roles (i.e. Does the current user have the required role access to the account & application?).

Knock-on effects

The following processors have been retired:

  • user_login.
  • user_logout.

Nearly all core resources have been updated use the new processors:

  • generate_token (generate a valid JWT token for a user, with custom claims: uid, user roles).
  • validate_token (validate the Authorization token as a valild JWT token).
  • validate_token_roles ((validate the Authorization token as a valild JWT token and also validation the user has the correct role permissions for the resource).
  • bearer_token (not used by core atm, but preserved for any processors that need access to the bearer token).

Processors have been optimised, now that they do not need to do any pre-validation on who can do what – this is left to the core resource definitions.

Tests are updated to incorporate the changes, and also now have multiple test users with different roles.

The good news

Not only has this significantly improved the API response time, it has now made the API much more scalable for enterprise. We communicated and researched several major 3rd party authorisation services, including auth0, to make sure that the decision to move to JWT tokens and custom claims would still be viable if a 3rd party auth server was used.

Most 3rd party authorisation services implement linking into external databases, so that would take the heat off the api server for token generation, and allow the token generation to be completely decoupled from ApiOpenStudio. This will be the subject of a future post.

WP Twitter Auto Publish Powered By : XYZScripts.com