can't use langflow store as i can't generate api key

[AhmedElghazaly]

D:\2- Mine\Pro\Py\projects\AC\The_Future\Ai_Agents\ai_agents\lib\site-packages\langflow\alembic\env.py:82: SAWarning: WARNING: SQL-parsed foreign key constraint '('user_id', 'user', 'id')' could not be located in PRAGMA foreign_keys for table credential
context.run_migrations()
D:\2- Mine\Pro\Py\projects\AC\The_Future\Ai_Agents\ai_agents\lib\site-packages\langflow\alembic\env.py:82: SAWarning: WARNING: SQL-parsed foreign key constraint '('user_id', 'user', 'id')' could not be located in PRAGMA foreign_keys for table flow
context.run_migrations()
No new upgrade operations detected.
D:\2- Mine\Pro\Py\projects\AC\The_Future\Ai_Agents\ai_agents\lib\site-packages\langflow\alembic\env.py:82: SAWarning: WARNING: SQL-parsed foreign key constraint '('user_id', 'user', 'id')' could not be located in PRAGMA foreign_keys for table credential
context.run_migrations()
D:\2- Mine\Pro\Py\projects\AC\The_Future\Ai_Agents\ai_agents\lib\site-packages\langflow\alembic\env.py:82: SAWarning: WARNING: SQL-parsed foreign key constraint '('user_id', 'user', 'id')' could not be located in PRAGMA foreign_keys for table flow
context.run_migrations()
No new upgrade operations detected.

[bc-teixeira]

Same here

[augmentedstartups]

same here

[ogabrielluiz]

Hi!

Do you all have access to the Langflow Store? The API key is generated there.

[dustyatx]

@ogabrielluiz It looks like new registrations are offline, either that or the auth is broken. Whenever I try to register or login, it just loops back to the login page.

I know they have been acquired by Datastax but I'd hope they wouldn't shut out new users during the transition.

[hchafiio]

same here

[vertgo]

Same here

[GQAdonis]

I have assembled some notes below that may crack the code of how store API keys are used, how LangFlow interacts with a Directus instance using that API key to manage components, etc. Hopefully the following is helpful, as I tried to derive an Open API schema that can be used to perhaps provide your own store implementation. I plan to use Supabase to implement mine, using edge functions to provide the same URL resource pattern expected by this code:

To provide a comprehensive analysis of the provided code, let's break it down into its components, focusing on its functionality, interaction with Directus, and how it manages the store. Afterward, I'll attempt to construct an OpenAPI 3 schema for the calls made to the Directus "store" instance.

Code Analysis

Overview

The code is a Python module designed to interact with a Directus-based store for managing components in the LangFlow application. It includes functionality for creating, querying, downloading, liking, and updating components, as well as managing user data and tags.

Key Classes and Functions

• StoreService Class: This is the main class that provides methods to interact with the store. It uses the httpx library for asynchronous HTTP requests to the Directus API.

• user_data_context Function: An asynchronous context manager that sets user data in a context variable based on an API key. This is used to fetch and temporarily store user data for the duration of a request.

• StoreService Methods:

  • _get: A utility method for performing GET requests to the Directus API.
  • check_api_key: Validates the provided API key by attempting to fetch user data.
  • call_webhook: Calls a specified webhook URL, used for download and like actions.
  • build_tags_filter and build_search_filter_conditions: Helper methods to construct filter conditions for querying components based on tags or search queries.
  • query_components: Queries components from the store based on various filters and conditions.
  • download and upload: Methods for downloading and uploading components to the store.
  • like_component: Allows a user to like a component.
  • get_list_component_response_model: Aggregates data for a list of components, including pagination and authorization checks.

Interaction with Directus

The code interacts with Directus primarily through HTTP requests to the Directus API endpoints. It uses bearer token authentication (Authorization: Bearer {api_key}) for requests that require user authorization. The Directus instance manages components as items within a collection, likely named components, and uses standard Directus features like filtering, sorting, and aggregation to query and manipulate these items.

OpenAPI 3 Schema Construction (Hypothetical)

Given the code's functionality, an OpenAPI 3 schema for the Directus "store" instance might include endpoints for components, users, and tags. Here's a simplified example for components:

openapi: 3.0.0
info:
  title: LangFlow Store API
  version: 1.0.0
paths:
  /items/components:
    get:
      summary: List components
      parameters:
        - in: query
          name: filter
          schema:
            type: string
          description: JSON-encoded filter conditions
        - in: query
          name: sort
          schema:
            type: string
          description: Fields to sort by
        - in: query
          name: page
          schema:
            type: integer
          description: Page number for pagination
        - in: query
          name: limit
          schema:
            type: integer
          description: Number of items per page
      responses:
        '200':
          description: A list of components
          content:
            application/json:
              schema:
                type: object
                properties:
                  data:
                    type: array
                    items:
                      $ref: '#/components/schemas/Component'
                  meta:
                    $ref: '#/components/schemas/MetaData'
    post:
      summary: Create a new component
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/ComponentCreate'
      responses:
        '200':
          description: The created component
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Component'
components:
  schemas:
    Component:
      type: object
      properties:
        id:
          type: string
          format: uuid
        name:
          type: string
        description:
          type: string
        tags:
          type: array
          items:
            type: string
    ComponentCreate:
      type: object
      properties:
        name:
          type: string
        description:
          type: string
        tags:
          type: array
          items:
            type: string
    MetaData:
      type: object
      properties:
        totalItems:
          type: integer
        itemCount:
          type: integer
        itemsPerPage:
          type: integer
        totalPages:
          type: integer
        currentPage:
          type: integer

This schema is a simplified example and would need to be expanded based on the full Directus schema for the LangFlow store, including authentication and error handling components.

Store API Key Validation

The validation of the store API key in the provided code base is performed through a combination of methods within the StoreService class, specifically through the check_api_key method. Here's a breakdown of how the API key validation process works:

Step 1: Sending a Request to Directus

The check_api_key method attempts to validate the API key by making a GET request to the Directus API endpoint /users/me, which is designed to return information about the current user based on the provided API key. The method constructs this request by appending /users/me to the base URL of the store (Directus instance) and includes the API key in the request headers as a Bearer token.

Step 2: Analyzing the Response

Upon receiving the response from Directus, the method checks if the response contains a user ID ("id" in the user data). If the user ID is present, it indicates that the API key is valid because Directus has successfully returned information about the user associated with that API key.

Step 3: Handling Errors and Status Codes

The method also includes error handling for HTTP status codes and other exceptions:

• If a HTTPStatusError is caught and the status code is either 403 (Forbidden) or 401 (Unauthorized), the method concludes that the API key is invalid. These status codes indicate that the provided API key does not have the necessary permissions or is not recognized by Directus.
• For any other unexpected status code or exception, the method raises a ValueError with details about the error, indicating that the API key validation process encountered an unexpected issue.

Code Snippet for check_api_key

async def check_api_key(self, api_key: str):
    try:
        user_data, _ = await self._get(f"{self.base_url}/users/me", api_key, params={"fields": "id"})
        return "id" in user_data[0]
    except HTTPStatusError as exc:
        if exc.response.status_code in [403, 401]:
            return False
        else:
            raise ValueError(f"Unexpected status code: {exc.response.status_code}")
    except Exception as exc:
        raise ValueError(f"Unexpected error: {exc}")

Summary

The validation of the store API key is essentially a process of making an authenticated request to a known Directus endpoint that requires valid authentication. If the request succeeds and returns user data, the API key is considered valid. If the request fails with specific status codes related to authentication or permissions, or if no user data is returned, the API key is considered invalid. This method leverages Directus's built-in authentication and user management to verify API keys.

[ogabrielluiz]

We are working getting everyone off the waitlist very soon.