#api-server #axum-server #configuration #authentication #api-version #path #open-api

axum-containerssh

This OpenAPI document describes the API endpoints that are required for implementing an authentication and configuration server for ContainerSSH. (See https://github.com/containerssh/libcontainerssh for details.)

2 releases

0.5.0 Jan 25, 2024
0.5.0-crt1 Feb 15, 2024

#249 in HTTP server

Download history 9645/week @ 2024-07-21 9905/week @ 2024-07-28 10618/week @ 2024-08-04 8977/week @ 2024-08-11 10603/week @ 2024-08-18 4942/week @ 2024-08-25 4754/week @ 2024-09-01 4057/week @ 2024-09-08 3517/week @ 2024-09-15 3670/week @ 2024-09-22 539/week @ 2024-09-29 578/week @ 2024-10-06 1088/week @ 2024-10-13 1060/week @ 2024-10-20 767/week @ 2024-10-27 796/week @ 2024-11-03

3,749 downloads per month

Apache-2.0

1.5MB
29K SLoC

Rust API for axum-containerssh

This OpenAPI document describes the API endpoints that are required for implementing an authentication and configuration server for ContainerSSH. (See https://github.com/containerssh/libcontainerssh for details.)

Overview

This server was generated by the [openapi-generator] (https://openapi-generator.tech) project. By using the OpenAPI-Spec from a remote server, you can easily generate a server stub.

To see how to make this your own, look here: README

  • API version: 0.5.0
  • Build date: 2024-01-25T16:54:36.302357845ZEtc/UTC

This autogenerated project defines an API crate axum-containerssh which contains:

  • An Api trait defining the API in Rust.
  • Data types representing the underlying data model.
  • Axum router which accepts HTTP requests and invokes the appropriate Api method for each operation.
    • Request validations (path, query, body params) are included.

Using the generated library

The generated library has a few optional features that can be activated through Cargo.

  • server
    • This defaults to enabled and creates the basic skeleton of a server implementation based on Axum.
    • To create the server stack you'll need to provide an implementation of the API trait to provide the server function.
  • conversions
    • This defaults to disabled and creates extra derives on models to allow "transmogrification" between objects of structurally similar types.

See https://doc.rust-lang.org/cargo/reference/manifest.html#the-features-section for how to use features in your Cargo.toml.

Example

struct ServerImpl {
   // database: sea_orm::DbConn,
}

#[allow(unused_variables)]
#[async_trait]
impl axum-containerssh::Api for ServerImpl {
  // API implementation goes here
}

pub async fn start_server(addr: &str) {
    // initialize tracing
    tracing_subscriber::fmt::init();

    // Init Axum router
    let app = axum-containerssh::server::new(Arc::new(ServerImpl));

    // Add layers to the router
    let app = app.layer(...);

    // Run the server with graceful shutdown
    let listener = TcpListener::bind(addr).await.unwrap();
    axum::serve(listener, app)
        .with_graceful_shutdown(shutdown_signal())
        .await
        .unwrap();
}

async fn shutdown_signal() {
    let ctrl_c = async {
        signal::ctrl_c()
            .await
            .expect("failed to install Ctrl+C handler");
    };

    #[cfg(unix)]
    let terminate = async {
        signal::unix::signal(signal::unix::SignalKind::terminate())
            .expect("failed to install signal handler")
            .recv()
            .await;
    };

    #[cfg(not(unix))]
    let terminate = std::future::pending::<()>();

    tokio::select! {
        _ = ctrl_c => {},
        _ = terminate => {},
    }
}

Dependencies

~16–28MB
~483K SLoC