Skip to content

LUNA PLATFORM v.5.30.0#

Summary#

  • New mechanism was added to implement the role model in LP 5. It provides the ability to create accounts with a certain data visibility area and issue tokens for them with differentiation of rights to access LP resources within the account for which the token was created.

    Now, most requests require an account, except for requests that do not require authorization.

    All accounts created using the Admin service will be automatically migrated. To save the ability to work with data previously created using the "Luna-Account-Id" header, you need to create a new account, specifying the previously used "account_id" when creating it. For the Backport 3 service, you need to run the migration script separately.

    See a detailed description of the new authorization system and account migration below or in the "Accounts, tokens and authorization types" section of the administrator manual.

    Accounts

    The account is required to delimit the visibility areas of objects for a particular user. Each created account has its own unique "account_id".

    The account can be created using a POST request "create account" to the API service, or by requesting "register account", or using the Admin user interface. When creating the account, you must specify the following data: login (email), password and account type.

    The account type determines what data is available to the user.

    • user - the type of account with which you can create objects and use only your account data.
    • advanced_user - the type of account for which rights similar to "user" are available, and there is access to the data of all accounts. Access to data from other accounts means the ability to receive data (GET requests), check their availability (HEAD requests) and perform comparison requests based on data from other accounts.
    • admin - the type of account for which rights similar to "advanced_user" are available, and there is also access to the Admin service (see "Admin service" below).

    Using the "Luna-Account-Id" header in the "create account" request, you can set the desired account ID. It should also be used if it is necessary to preserve the ability to work with data created in LP versions up to 5.30.0 (see "Migrating accounts from previous builds of LP 5" below).

    Tokens

    Token is linked to an existing account with any type and enables you to impose extended restrictions on the requests being made. For example, when creating the token, you can give the user permission only to create and modify all lists and faces, or you can prevent the use of certain handlers by specifying their ID.

    The token and all its permissions are stored in the database and linked to the account by the "account_id" parameter.

    When creating the token, you can set the following parameters:

    • expiration_time – expiration time of the token in RFC 3339 format. You can specify an infinite token expiration time using the value "null"
    • permissions – permissions that are available to the user
    • visibility_area – token visibility of data from other accounts (see the section "Viewing other account data" in the administrator manual)

    See the list of all permissions and detailed information on tokens in the "Permissions set in token" section of the administrator manual.

    Authorization types for accessing resources

    There are three types of authorization available in LUNA PLATFORM:

    • BasicAuth. Authorization by login and password (set during account creation).
    • BearerAuth. Authorization by JWT token (issued after the token is created).
    • LunaAccountIdAuth. Authorization by "Luna-Account-Id" header, which specifies the "account_id" generated after creating the account (this method was adopted as the main one before version 5.30.0).

    LunaAccountIdAuth authorization has the lowest priority compared to other methods and can be disabled using the "ALLOW_LUNA_ACCOUNT_AUTH_HEADER" setting in the "OTHER" section of the API service settings in the Configurator (enabled by default). In the OpenAPI specification the "Luna-Account-Id" header is marked with the word Deprecated.

    Admin service

    The account can still be managed using the Admin service. The service's user interface was updated. Now the account creation dialog contains an expanded set of fields.

    The old administrator account was converted to the account with the "admin" type. The default login is now root@visionlabs.ai instead of root.

    When deploying LP 5 from scratch, the database is no longer created for the Admin service. Now account data is stored in the Accounts database (see "Admin database migration" below).

    Migrating accounts from previous builds of LP 5

    Previously, the account was created using the "/accounts" resource of the Admin service or the user interface of the Admin service.

    All accounts created before the current version will be automatically migrated when updating to the current version. The administrator account will be assigned the type "admin", and the accounts created when requesting the resource "/accounts" will be assigned the type "advanced_user". The email address will be used as the login and password. The name of the organization will be written in the "description" field.

    It was also previously possible to make requests to LP 5 services by specifying the "account_id" in the "Luna-Account-Id" header. In order to preserve the ability to work with data created earlier by specifying the "account_id" in the "Luna-Account-Id" header, it is necessary to specify "login", "password", "account_type" and the old "account_id" in the "Luna-Account-Id" header in the account creation request. Thus, the old "account_id" will be linked to the account being created.

    Admin database migration

    Previously, account data was stored in the Admin database.

    If the LP is deployed for the first time, the Accounts database will be created with which the Accounts service interacts. If LP is updated from version 5.28.0 or lower, the Admin database will be converted to work with accounts, and the Admin service will no longer interact with the Admin database.

    The section "Admin DB transformation" was added to the LP 5 upgrade manual, as well as the section "Account creation using API service", where an example of a CURL request for creating a new account and migrating the account if its "account_id" was used in the "Luna-Account-Id" header without creating account in the Admin service.

    Migrating accounts from previous versions of Backport 3

    When upgrading from the previous version of Backport 3, to migrate accounts, you must additionally run the migration script after migrating the Backport 3 database (see the "Accounts and tokens migration" section in the LP 5 upgrade manual).

    Migrating accounts from LP 3.3.8

    When upgrading from LUNA PLATFORM 3.3.8, accounts will be migrated when running the "start_migration.py" script (see "Migration script description" in the LUNA PLATFORM 3.3.8 migration manual).

    Migrating accounts from LP 4.5.4

    When upgrading from LUNA PLATFORM 4.5.4, accounts are migrated in the same way as described in "Migrating accounts from previous builds of LP 5" and "Admin database migration" above. The section "Admin DB transformation" was added to the LUNA PLATFORM 4.5.4 migration manual, as well as the section "Account creation using API service", where an example of a CURL request for creating a new account and migrating the account if its "account_id" was used in the "Luna-Account-Id" header without creating account in the Admin service.

    Backport 4 service

    The ability to authorize by login and password (BasicAuth) and by account ID (LunaAccountIdAuth) was added to the Backport 4 API . Authorization by token (BearerAuth) is not possible.

    The User Interface 4 service now uses login and password authorization ("BASIC_AUTH" parameter in the .env file) instead of "account_id" ("LUNA_ACCOUNT_ID" parameter in the .env file). Login and password must be specified in the "login:password" format in Base64.

  • The number of received and deleted faces, tasks, handlers, events and LP settings specified in the "page_size" parameters of various resources and services was increased from 100 to 1000.

  • New section "EXTERNAL_LUNA_API_ADDRESS" was added to the settings of the Handlers and Tasks services, intended to correctly process links to objects created using the "/images" and "/objects" resources in the API service. This section specifies the address and API version of the API service.

    If as input for resources "/detector", "handlers/{handler_id}/events", "/iso", "/sdk" and "verifiers/{verifier_id}/verification" specifies the URL and version of the API service of the "images" type object that matches the address and version of the API from the "EXTERNAL_LUNA_API_ADDRESS" section of the Handlers service settings, then these objects will be loaded using the Image Store service directly, and not send a request to the API service from subsequent redirection to the Image Store service.

    Format example: "http://10.15.3.144:5000/6/images/141d2706-8baf-433b-82eb-8c7fada847da", where "http://10.15.3.144:5000" must match the value from the "origin" setting ", and the value 6 must match the value of the "api_version" setting in the "EXTERNAL_LUNA_API_ADDRESS" section.

    If the "content" > "source" > "reference" parameter of the resource "/tasks/estimator" specifies the URL and version of the API service of the "object" (ZIP archive) type object that matches the address and version of the API from the section "EXTERNAL_LUNA_API_ADDRESS" of the Tasks service settings, then this object will be loaded using the Image Store service directly, rather than sending a request to the API service with subsequent redirection to the Image Store service.

    To avoid errors, you must configure this section in the Handlers or Tasks settings before using URLs to objects of type "objects" or "images" as an input source.

  • Vendor libraries for HASP key and HASP utility were updated.

    Now the "haspvlib_x86_64_111186.so" and "haspvlib_111186.so" libraries are replaced by the "haspvlib_x86_64_30147.so" and "haspvlib_30147.so" libraries, and the "aksusbd-8.23-1.x86_64.rpm" utility is replaced by the "aksusbd-8.43-1.x86_64.rpm" utility.

    When upgrading to a new LP build, you need to remove the old libraries and the HASP utility and install the new ones. The Licenses service will not start if the utility and libraries of previous versions are used.

    You also need to contact technical support to reissue the LUNA PLATFORM 5 key.

Fixed errors

  • The error was fixed, in which the request to the "4/healthcheck" resource returned the error "Internal server error" when the Tasks service was disabled in the "ADDITIONAL_SERVICES_USAGE" section of the Configurator service.

  • The error was fixed, in which the request to the resource "/luna_sys_info" returned the error "Internal server error" if the license file did not have the function of performing image checks for compliance with standards in the resources "/iso", "/detector" , "/handlers" and "/verifiers".

  • The error in the OpenAPI specification was fixed, in which the "get task result" and "generate events" response schemes displayed the type "Nullable" for some "face_quality" thresholds.

API (v.6.3.4 - v.6.4.1)#

Improvements#

  • Service dependencies were updated.

  • The new resources were added, see:

  • The accounting mechanism was significantly reworked. See accounting for details.

  • Max page size was increased up to 1000.

  • Events generation processing was updated.

    For requests with limited visibility area, from now on the dynamic handler's account_id will be used as matching candidates filter.

  • Estimator task processing was updated.

    For requests with limited visibility area, from now on: if no account_id specified for matching candidates (in task's content handler matching policy), the handler's account_id will be used be default.

Fixed bugs#

Faces (v.4.4.52 - v.4.5.1)#

Improvements#

  • Service dependencies were updated.

  • The account_id parameter has been moved from request body to the Luna-Account-Id header.

    The parameter format and purpose remain the same.

    Relevant for the following requests:

  • Database matching function description moved to "Luna-Python-Matcher".

  • Max page size was increased up to 1000.

Image Store (v.3.5.17 - v.3.6.2)#

Improvements#

  • Service dependencies were updated.

  • The account_id parameter has been moved from request body to the Luna-Account-Id header.

    The parameter format and purpose remain the same.

    Relevant for the following requests:

Accounts (v.0.0.1 - v.0.0.2)#

Improvements#

  • Service dependencies were updated.

  • Max page size was increased up to 1000.

Tasks (v.3.9.10 - v.3.10.1)#

Improvements#

Events (v.4.1.5 - v.4.2.1)#

Improvements#

  • Service dependencies were updated.

  • The account_id parameter has been moved from request body to the Luna-Account-Id header.

    The parameter format and purpose remain the same.

    Relevant for the following requests: create events

Configurator (v.2.0.47 - v.2.0.51)#

Improvements#

  • Service dependencies were updated.

  • Max page size was increased up to 1000.

Sender (v.2.4.7 - v.2.4.11)#

Improvements#

  • Service dependencies were updated.

Admin (v.4.6.40 - v.4.7.1)#

Improvements#

  • Service dependencies were updated.

  • The new Luna Accounts service is now used for accounting. Admin database is no longer in use.

    Account registering with email is deprecated, see accounts for details.

  • Max page size was increased up to 1000.

Fixed bugs#

  • Fixed healthcheck request when luna-tasks service is disabled in ADDITIONAL_SERVICE_USAGE setting.

  • Internal server error that was appearing in configurations without ISO licensing feature was fixed.

Licenses (v.0.3.54 - v.0.3.58)#

Improvements#

  • Service dependencies were updated.

  • Hasp vendor lib was updated. Previous hasp licences will not work with new lib.

Handlers (v.2.7.5)#

Improvements#

  • Service dependencies were updated.

Python Matcher and Python Matcher Proxy (v.1.1.10 - v.1.1.14)#

Improvements#

  • Service dependencies were updated.

  • Database matching function description was moved from the Luna-Faces and Luna-Events services to the Luna-Python-Matcher service, see Database.

  • Package luna-plugins is used for plugins mechanics. Plugins examples was updated.

Backport3 (v.0.3.50 - v.0.4.1)#

Improvements#

  • Service dependencies were updated.

  • The new Luna Accounts service is now used for accounting. Account data is no longer stored in the Backport3 database.

  • Max page size was increased up to 1000.

Backport4 (v.1.2.50 - v.1.2.54)#

Improvements#

  • Service dependencies were updated.

  • From now on Luna-Backport4 does not use Luna-Sender directly, all websocket requests will now redirected to Luna-Api service.

  • Max page size was increased up to 1000.