Oauth v2 Provider ME (MongoDB + Express)

When you develop your APIs, you need to secure the resources they will offer. The Oauth 2 framework offers a safe and secure way to achieve this.

This package is an OAuth 2.0 Authorization Server with mongoose, Express and EJS.

While developing app using MEAN (MongoDB + Express+ Angular + Node.js), MERN (MongoDB + Express+ React.js + Node.js) or globally ME*N stack you can use this package to host a Oauth 2 server.

Table of Contents

[TOC]

Implemented specifications & Features

RFC6749 - OAuth 2.0
- [x] Authorization (Authorization Code Flow, Implicit Flow)
- [x] Client Credentials Grant
- [x] Password Grant
RFC7636 - Proof Key for Code Exchange (PKCE))
- [x] Authorization code with PKCE
RFC 7009 - Oauth 2 Token Revocation
- [x] Token Revocation
OpenID Connect Core 1.0
- [ ] ID Token (soon)

Installation

Installation command

npm  install @noreajs/oauth-v2-provider-me --save

The package already content it's types definition.

Configuration

Initialization

The provider is initialize with a simple function.

Initialization function definition

Oauth.init(app: Application, initContext: IOauthContext): void

The IOauthContext is an object with some properties useful for the provider configuration.

Property	Type	Optional	Description
providerName	string	false	Oauth v2 provider name. This name is going to be used as cookie name.
secretKey	string	false	Oauth v2 provider secret key
jwtAlgorithm	"HS256", "HS384", "HS512", "RS256", "RS384", "RS512", "ES256", "ES384", "ES512"	true	Jwt encrypt algorithm
authenticationLogic	Function	false	Function which take username and password as parameters and authenticate related user. Response can be an object of type `IEndUserAuthData` or `undefined`
supportedOpenIdStandardClaims	Function	false	Function that return claims to be included in id_token. Response can be an object of type `JwtTokenReservedClaimsType` or `undefined`
subLookup	Function	true	Lookup the token owner and make his data available in Express response within the `locals` property or express Response
securityMiddlewares	array	true	Middlewares to be applied to Clients management routes and Scopes management routes
tokenType	"Bearer"	true	Token type will be always Bearer
authorizationCodeLifeTime	object	true	Authorization code lifetime in seconds
accessTokenExpiresIn	object	true	Access Token Expiration Times
refreshTokenExpiresIn	object	true	Refresh Token Expiration Times

Oauth context default values:

jwtAlgorithm: "HS512"
securityMiddlewares: []
tokenType: "Bearer"
authorizationCodeLifeTime: 60 * 5 // 5 minutes
accessTokenExpiresIn

{
    confidential: {
        internal: 60 * 60 * 24, // 24h
        external: 60 * 60 * 12, // 12h
    },
    public: {
        internal: 60 * 60 * 2, // 2h
        external: 60 * 60, // 1h
    }
}

refreshTokenExpiresIn

{
    confidential: {
        internal: 60 * 60 * 24 * 30 * 12, // 1 year
        external: 60 * 60 * 24 * 30, // 30 days
    },
    public: {
        internal: 60 * 60 * 24 * 30, // 30 days
        external: 60 * 60 * 24 * 7, // 1 week
    }
}

Initialization with common Node.js + Express example

import express from "express";
import { Oauth, IEndUserAuthData, JwtTokenReservedClaimsType } from "@noreajs/oauth-v2-provider-me";

const app = express();

Oauth.init(app, {
    providerName: "Your App Name",
    secretKey: "66a5ddac054bfe9389e82de--your-secret-key--a7488756a00ca334a1468015da8",
    authenticationLogic: async function (username: string, password: string) {
      // Your authentication logic here
    },
    supportedOpenIdStandardClaims: async function (userId: string) {
      // Return supported Open ID standard claims
    },
    subLookup: async (sub: string) => {
      // returns the user who has an identifier equal to sub
    },
    securityMiddlewares: [
      // Oauth.authorize() - Add this middleware only on production mode
    ],
});

// start the app
app.listen(3000, function () {
    console.log('Example Oauth 2 server listening on port 3000!')
})

Session

This package uses Express session for session management during authentication operations. You can initialize Express session session in two ways.

Before Oauth initialization

import express from "express";
import session from "express-session";

const app = express();

// inject session
app.use(session({
    secret: 'keyboard cat',
    resave: false,
    saveUninitialized: true,
    cookie: { secure: true }
}))

// initialize oauth now

During Oauth initialization

import express from "express";
import { Oauth } from "@noreajs/oauth-v2-provider-me";

const app = express();

// initialize Oauth v2 provider
Oauth.init(app, {
    providerName: "Your App Name",
    // ...some options
}, {
    sessionOptions: {
        resave: false,
        saveUninitialized: true,
        cookie: { secure: true }
	}
});

Session Store Implementation

Express-session middleware stores session data on the server; it only saves the session ID in the cookie itself, but not the session data. By default, it uses memory storage and is not designed for a production environment. In production, you will need to configure a scalable session store.

MongoDB session store example - MongoDBStore

import express from "express";
import session from "express-session";
import mongodbSession from "connect-mongodb-session";

const MongoDBStore = mongodbSession(session);

const app = express();

// inject session
app.use(session({
    secret: 'keyboard cat',
    // ... some options
    // mongoDB store session initialization
    store: new MongoDBStore({
        uri: 'mongodb://localhost:27017/connect_mongodb_session_test',
        collection: 'mySessions'
    })
}))

// initialize oauth now

See the list of other compatible session stores

Manage scopes

To make your API more secure, Each route should be associated with one or more scopes.

Some endpoints are already provided with the package to manage scopes:

HTTP Method	Route	Description
GET	/oauth/v2/scopes	Get all scopes
GET	/oauth/v2/scopes/:id	Get scope by ID
POST	/oauth/v2/scopes	Create a new scope
PUT	/oauth/v2/scopes/:id	Edit a scope
DELETE	/oauth/v2/scopes/:id	Delete a scope

Scope properties

Property Name	Type	Optional	Description
name	string	false	Name of the scope. String without space.
description	string	true	Description of the scope
parent	ObjectId	true	To better organize the scopes, some can have parents.

Scope creation's body request example

{
    "name": "edit:user",
    "description": "Edit a user account"
}

Manage clients

Developers building applications that need to interact with your application's API will need to register their application with yours by creating a "client".

Client endpoints

Some endpoints are already provided with the package to manage clients:

HTTP Method	Route	Description
GET	/oauth/v2/clients	Get all clients
GET	/oauth/v2/clients/:id	Get client by ID
POST	/oauth/v2/clients	Create a new client
PUT	/oauth/v2/clients/:id	Edit a client
DELETE	/oauth/v2/clients/:id	Delete a client

Client properties

To respect Oauth 2 specifications some properties are needed for the client.

Property Name	Type	Optional	Description
clientId	string	Generated	Client ID
name	string	false	Name of the application
domaine	string	true	Domaine name of the application
logo	string	true	Link of the application logo
description	string	true	Description of the application
secretKey	string	generated	Secret key of the client. It is only generated when the clientType value is confidential.
internal	boolean	false	Set internal value to true for First-party applications and false for Third-party applications
grants	array of values in implicit, client_credentials, password, authorization_code and refresh_token	Automatically filled based on data provides	Allowed grants depends on whether the client is confidential or public, internal or external.
redirectURIs	array of URI	false	After a user successfully authorizes an application, the server will redirect the user back to the application with either an authorization code or access token in the URL
clientProfile	web, user-agent-based or native	false	web for web application, user-agent-based for user-agent based application, and native for native desktop or mobile application.
clientType	confidential or public	Automatically filled based on clientProfile value	A confidential client is a client who guarantees the confidentiality of credentials (Web application with a secure backend). A public client cannot hold credentials securely (native desktop or mobile application, user-agent-based application such as a single page app).
programmingLanguage	string	true	Language used to develop the application
scope	string	false	Scope requested by the application (i.e. "read:users list:users add:users")

Other client properties:

legalTermsAcceptedAt (OPTIONAL): if some legal terms need to be accepted before consuming your API.
revokedAt (OPTIONAL): filled when the client is revoked

Revoke a client

To revoke a client, use the edit endpoint and send data as follow:

{
    // ... other fields
    revoke: true // you can also end false in other to cancel revokation
}

Client types detailed

OAuth defines two client types, based on their ability to authenticate securely with the authorization server.

confidential
- Web application: Application were views are generated from a server. The following list is not exhaustive.
  - JavaScript - Node.js (Express)
  - C# – ASP.NET MVC
  - Java – Spring MVC, Apache Struts, Play Framework
  - Groovy – Grails Framework
  - Python – Django
  - Ruby – Ruby on Rails
  - PHP – Laravel
public
- Browser-based application: Most of SPA application based on Web browser JavaScript frameworks and libraries such as:
  - AngularJs
  - Ember.Js
  - ExtJS
  - Meteor.js
  - React.js
  - Vue.js
- Native application: software program that is developed for use on a particular platform or device
  - Mobile applications: Android, IOS and Windows phone
  - Desktop application: Linux, windows, Mac OS

Client example

Client creation's request body example

{
    name: "Cake Shop",
    internal: false,
    redirectURIs: ["https://www.cakeshop.com/auth/callback"],
    clientProfile: "web",
    scope: "read:users read:cake add:cakes" // "*" is allowed only for internal client
}

Authorization Grants

Depending on the type of customers who want to access your API, there are appropriate types of authentication.

Authorization Code Grant

The authorization code grant type is the most commonly used because it is optimized for server-side applications, where source code is not publicly exposed, and Client Secret confidentiality can be maintained. This is a redirection-based flow, which means that the application must be capable of interacting with the user-agent (i.e. the user’s web browser) and receiving API authorization codes that are routed through the user-agent.

Creating The Client

Targeted applications:

Public and confidential web frontend application - web app or browser-based app
Native frontend application - mobile or desktop app

Request body example:

{
    name: "App Name",
    internal: true,
    redirectURIs: ["https://www.app_name.com/auth/callback"],
    clientProfile: "web",
    scope: "*"
}

Requesting Tokens

Once a client has been created, developers may use their client ID and secret to request an authorization code and access token from your application.

Get authorization codes

HTTP Method: GET
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/authorize
Query parameters:

{
    client_id: "client-id",
    redirect_uri: "http://example.com/callback",
    response_type: "code",
    scope: "", // OPTIONAL
    state: "" // OPTIONAL but highly recommended
}

Note: client_id and client_secret can be sent via Basic authorization header and not in the request body.

Authorization: Basic {BASE64URL-ENCODE(client_id:client_secret)}

After sending this request, the client will be redirect to an authentication page. Once the end-user authenticated, he will be redirected to the provided redirect_uri with the authorization code.

The given authorization code will be used to request access token in the next step.

Converting Authorization Codes To Access Tokens

HTTP Method: POST
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/token
Query body:

{
    grant_type: "authorization_code", 
    client_id: "client-id",
    client_secret: "client-secret", // required only for confidential client
    redirect_uri: "http://example.com/callback",
    code: "code" // code previously received
}

Note: client_id and client_secret can be sent via Basic authorization header and not in the request body.

Authorization: Basic {BASE64URL-ENCODE(client_id:client_secret)}

Try with Postman (You can also try with other rest API client)

Configure a single request
- Create a new request
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token
- Select Authorization Code as Grant Type value
- Fill the rest of the form with the data of the client that you created before
Configure a folder
- Right click on the folder and Click on Edit
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token
- Select Authorization Code as Grant Type value
- Fill the rest of the form with the data of the client that you created before

Authorization Code Grant with PKCE

The Authorization Code grant with "Proof Key for Code Exchange" (PKCE) is a secure way to authenticate public client. You use it when there is not guarantee that the client client can store secret key confidentially.

This grant is based on a "code verifier" and a "code challenge".

Code Verifier & Code Challenge

As this authorization grant does not provide a client secret, developers will need to generate a combination of a code verifier and a code challenge in order to request a token.

The code verifier should be a random string of between 43 and 128 characters containing letters, numbers and "-", ".", "*", "~", as defined in the RFC 7636 specification.

The code challenge should be a BASE64URL-ENCODE encoded string with URL and filename-safe characters. The trailing '=' characters should be removed and no line breaks, whitespace, or other additional characters should be present.

Creating The Client

Targeted applications:

Public web frontend application - web app or browser-based app
Native frontend application - mobile or desktop app

Request body example:

{
    name: "App Name",
    internal: false,
    redirectURIs: ["https://www.app_name.com/auth/callback"],
    clientProfile: "user-agent-based",
    scope: "read:users list:users"
}

Requesting Tokens

Once a client has been created, developers may use their client ID and secret to request an authorization code and access token from your application.

Get authorization codes

HTTP Method: GET
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/authorize
Query parameters:

{
    client_id: "client-id",
    redirect_uri: "http://example.com/callback",
    response_type: "code",
	code_challenge: "generated-code-challenge", // REQUIRED.  Code challenge.
    code_challenge_method: "S256", // OPTIONAL, defaults to "plain" if not present in the request.  Code verifier transformation method is "S256" or "plain".
    scope: "", // OPTIONAL
    state: "" // OPTIONAL but highly recommended
}

After sending this request, the client will be redirect to an authentication page. Once the end-user authenticated, he will be redirected to the provided redirect_uri with the authorization code.

The given authorization code will be used to request access token in the next step.

Converting Authorization Codes To Access Tokens

HTTP Method: POST
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/token
Query body:

{
    grant_type: "authorization_code",
    client_id: "client-id",
    redirect_uri: "http://example.com/callback",
    code_verifier: "codeVerifier",
    code: "code" // code previously received
}

Try with Postman (You can also try with other rest API client)

Configure a single request
- Create a new request
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token
- Select Authorization Code (With PKCE) as Grant Type value
- Fill the rest of the form with the data of the client that you created before
Configure a folder
- Right click on the folder and Click on Edit
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token
- Select Authorization Code (With PKCE) as Grant Type value
- Fill the rest of the form with the data of the client that you created before

Password Grant

The password grant allows confidential application to obtain an access token using an e-mail address / username and password. This allows you to issue access tokens securely to your first-party clients without requiring your users to go through the entire authorization code redirect flow.

Targeted clients:

This grant type should only be enabled on the authorization server if other flows are not viable. Also, it should only be used if first-party applications (e.g. : applications in your organization).

Creating A Password Grant Client

This grant is recommended for internal (First-party applications) applications:

Public or confidential web frontend application - web app or browser-based app
Native frontend application - mobile or desktop app

Request body example:

{
    name: "App Name",
    internal: true, // must be true for password grant
    redirectURIs: ["https://www.app_name.com/auth/callback"],
    clientProfile: "native",
    scope: "*"
}

Requesting Tokens

Once a client has been created, developers may use their client ID and secret to request an access token from your application.

The consuming application should send client ID, secret key, username and password to your application's /oauth/v2/token endpoint.

Request tokens

HTTP Method: POST
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/token
Query body:

{
    grant_type: "password",
    client_id: "client-id",
    client_secret: "client-secret",
    username: "john.conor@sky.net",
    password: "my-password",
    scope: "" // OPTIONAL
}

Note: client_id and client_secret can be sent via Basic authorization header and not in the request body.

Authorization: Basic {BASE64URL-ENCODE(client_id:client_secret)}

Try with Postman (You can also try with other rest API client)

Configure a single request
- Create a new request
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token
- Select Password Credentials as Grant Type value
- Fill the rest of the form with the data of the client that you created before
Configure a folder
- Right click on the folder and Click on Edit
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token
- Select Password Credentials as Grant Type value
- Fill the rest of the form with the data of the client that you created before

Implicit Grant

The implicit grant is similar to the authorization code grant; however, the token is returned to the client without exchanging an authorization code. This grant is most commonly used for JavaScript or mobile applications where the client credentials can't be securely stored.

The implicit grant type is used for mobile apps and web applications (i.e. applications that run in a web browser), where the client secret confidentiality is not guaranteed. The implicit grant type is also a redirection-based flow but the access token is given to the user-agent to forward to the application, so it may be exposed to the user and other applications on the user’s device.

Creating An Implicit Grant Client

Targeted applications:

Public web frontend application - browser-based app
Native frontend application - mobile or desktop app

Request body example:

{
    name: "App Name",
    internal: true,
    redirectURIs: ["https://www.app_name.com/auth/callback"],
    clientProfile: "user-agent-based",
    scope: "read:users list:users edit:users"
}

Request tokens

HTTP Method: POST
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/token
Query body:

{
    client_id: "client-id",
    redirect_uri: "http://example.com/callback",
    response_type: "token",
    scope: "", // OPTIONAL
    state: "state" // OPTIONAL but highly recommended
}

Try with Postman (You can also try with other rest API client)

Configure a single request
- Create a new request
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token and fill the form with the client data
- Select Implicit as Grant Type value
- Fill the rest of the form with the data of the client that you created before
Configure a folder
- Right click on the folder and Click on Edit
- Select Authorization tab
- Select Implicit as Grant Type value
- Fill the rest of the form with the data of the client that you created before

Client Credentials Grant

The client credentials grant is suitable for machine-to-machine authentication. Use it if you need for example two or more servers of your organization to communicate together.

The client credentials grant type provides an application a way to access its own service. Server to server communication in the same organization.

Creating An Client Credentials Grant Client

Targeted applications:

Confidential web application - frontend or backend

Request body example:

{
    name: "App Name",
    internal: true, // must be true for client credentials grant
    redirectURIs: ["https://www.app_name.com/auth/callback"],
    clientProfile: "web", // must be web for client credentials grant
    scope: "*"
}

Request token

HTTP Method: POST
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/token
Query body:

{
    grant_type: "client_credentials",
    client_id: "client-id",
    client_secret: "client-secret",
    scope: "client-requested-scope" // OPTIONAL
}

Note: client_id and client_secret can be sent via Basic authorization header and not in the request body.

Authorization: Basic {BASE64URL-ENCODE(client_id:client_secret)}

Try with Postman (You can also try with other rest API client)

Configure a single request
- Create a new request
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token
- Select Client Credentials as Grant Type value
- Fill the rest of the form with the data of the client that you created before
Configure a folder
- Right click on the folder and Click on Edit
- Select Authorization tab
- Select Oauth 2.0 within the Type
- Click on Get New Access Token
- Select Client Credentials as Grant Type value
- Fill the rest of the form with the data of the client that you created before

Refreshing Tokens

Token generated with some grants as Password Credentials Grant and Authorization Code Grant, come with a refresh token that the user can use to get a new token as follow.

Refresh token

HTTP Method: POST
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/token
Query body:

{
    grant_type: "refresh_token",
    refresh_token: "the-refresh-token",
    client_id: "client-id",
    client_secret: "client-secret",
    scope: "client-requested-scope" // OPTIONAL
}

Note: client_id and client_secret can be sent via Basic authorization header and not in the request body.

Authorization: Basic {BASE64URL-ENCODE(client_id:client_secret)}

Revoke Token

Refresh token and Access token can be revoked, In case you would like to disconnect a user.

Refresh token

HTTP Method: POST
Endpoint: {YOUR_API_BASE_URL}/oauth/v2/revoke
Query body:

{
    token_type_hint?: "refresh_token", // or "access_token";
  	token: "the-token",
  	client_id: "client-id", // OPTIONAL
  	client_secret: "client-secret" // OPTIONAL
}

Note: client_id and client_secret can be sent via Basic authorization header and not in the request body.

Authorization: Basic {BASE64URL-ENCODE(client_id:client_secret)}

Purging Tokens and Authorization codes

This package provide some endpoints to purge revoked or expired tokens and authorization codes.

Target	HTTP Method	Endpoint
Tokens	DELETE	/oauth/v2/purge/token
Authorization Codes	DELETE	/oauth/v2/purge/code
Tokens & Authorization Codes	DELETE	/oauth/v2/purge

By default, all expired or revoked tokens or codes are purged, but you may want to delete only revoked tokens or only expired tokens. To do this, you can pass the type parameter to your request, which can respectively take the values revoked or expired.

Example:

DELETE: {YOUR_API_BASE_URL}/oauth/v2/purge/token?type=revoked

Delete all revoked tokens
DELETE: {YOUR_API_BASE_URL}/oauth/v2/purge/code

Delete both revoked and expired authorization codes

Protecting Routes

Via Middleware.

You can secure your routes by adding the middleware Oauth.authorize(). It is a static method of the Oauth class provided by the package.

Method definition:

Oauth.authorize(scope?: string | undefined): (req: Request, res: Response, next: NextFunction) => Promise<Response<any> | undefined>

Import Oauth

import { Oauth } from "@noreajs/oauth-v2-provider-me";

// app is an express application or express router
app.route('/account/update').put([
    // ... other middleware
    Oauth.authorize(), // oauth middleware. It must always be before the protected resource
    // ... other middleware
    authController.update // protected resource
]);

Verify a token manually

In some use cases, you can recover the access token on your own. There is a method that allows you to verify a token: Oauth.verifyToken.

Example

import { Oauth } from "@noreajs/oauth-v2-provider-me";

// Token example
const accessToken = "euiaoejsjflsdfhoiuezioueiz.ieaoufisdfosdfusdfksdlkfjdkfjs.skdjflksdfjls";

Oauth.verifyToken(accessToken, (userId, lookupData) => {
	// userId : current user id
    // lookupData: current user data if the lookup method has been defined while initializing Oauth. 
    // lookupData is undefined for client_credentials grant
    next();
}, (reason: string, authError: boolean) => {
    // reason: is the description of the error
    if (authError) {
        // Authorization error
    } else {
        // internal error (e.g. Oauth 2 Server has not been initialized yet)
    }
}, scope)

Method prototype (Typescript)

Oauth.verifyToken(token: string, success: (userId: string, lookupData?: any) => Promise<void> | void, error: (reason: string, authError: boolean) => Promise<void> | void, scope?: string | undefined): Promise<void>

Secure Oauth 2 endpoints

While initializing the provider, there is a property called securityMiddlewares. Once your app if fully functional and ready for production you can secure Oauth 2 endpoints (Client management endpoints, purge endpoints).

securityMiddlewares initialization example

{
    // ... other initialization properties
    securityMiddlewares: [
        // other middlewares
        Oauth.authorize('create:clients list:clients purge:tokens purge:codes'),
        // other middlewares
    ],
    // ... other initialization properties
}

Checking Scopes

The scope(s) required for a resource can be passed via the Oauth.authorize method as follow:

app.route('/account/update').put([
    Oauth.authorize('edit:profile'),
    authController.update
]);

Note : Many scopes can be transmitted by separating them with a space.

Mongoose Models

The Mongoose models used by the package are accessible. You can use them as you wish.

Model Name	Collection Name	Description
OauthAccessToken	oauth_access_tokens	Manage access tokens
OauthAuthCode	oauth_auth_codes	Manage authorization codes
OauthClient	oauth_clients	Manage clients
OauthRefreshToken	oauth_refresh_tokens	Manage refresh tokens
OauthScope	oauth_scopes	Manage scopes

You can import these models as follows:

import { /* model_name*/ } from "@noreajs/oauth-v2-provider-me"

@noreajs/oauth-v2-provider-me

Oauth v2 Provider ME (MongoDB + Express)

Implemented specifications & Features

Installation

Configuration

Initialization

Session

Manage scopes

Manage clients

Client endpoints

Client properties

Revoke a client

Client types detailed

Client example

Authorization Grants

Authorization Code Grant

Authorization Code Grant with PKCE

Password Grant

Implicit Grant

Client Credentials Grant

Refreshing Tokens

Revoke Token

Purging Tokens and Authorization codes

Protecting Routes

Via Middleware.

Verify a token manually

Secure Oauth 2 endpoints

Checking Scopes

Mongoose Models

Consuming Your API With JavaScript (axios)

Readme

Keywords

Package Sidebar

Install

Repository

Homepage

DownloadsWeekly Downloads

Version

License

Unpacked Size

Total Files

Last publish

Collaborators

Weekly Downloads