• github grey
  • 600px-Deno-gr
  • medium grey-01
  • product hunt-gr
DASHPORT LOGO .png

DASHPORT 1.0

A Deno based authentication middleware module

for your local login and OAuth 2.0 development needs

  • github
  • deno

The Team

  • github
  • linkedin

Alex is a pretty cool old man, that has a kid. He lives in the woods and chases bears away with a stick, and he is a dad.

  • github
  • linkedin

Alvin is a full-stack software engineer who enjoys building tools to enhance developer efficiencies. He likes snowboarding and board gaming and one day wants to learn how to paramotor.

  • github
  • linkedin

Edward is a full stack software engineer and military computer engineer who loves to delve into new technologies and find out the best solution for problems in the engineering world. He likes to hike, experience nature, and participate in physical activities.

  • github
  • linkedin

Sam is a full stack software engineer who loves creating tech that helps organize our messy world. In his free time you can find him hiking in the white mountains, playing squash, writing bad lit fic, or learning about whatever random topic grabs his interest that week. 

  • github
  • linkedin

Wei is a full-stack software engineer in NYC who enjoys building exciting apps. In his down time, he loves listening to Darknet Diaries while training to break 3 hours in the next marathon. He also loves rock climbing in the summer in the Gunks mountains.  

 
 
DASHPORT SHIELD-02.png

Strategies

 

Press

 

Documentation

Dashport is a module that simplifies adding authentication middleware for Deno. Currently, the server framework being utilized is Oak, but Dashport has been modularized so that future frameworks can be easily added.

Dashport was inspired by Passport, the golden authentication middleware module for Node.js.

Getting started

To get started, import Dashport. For easier modularity, Dashport can be imported into its own file for configurations.

When Dashport is instantiated, pass in the server framework being used (Dashport currently only supports Oak). Then begin adding configurations for a serializer, deserializer, and strategy. Any errors returned from serializers and deserializers should be instances of 'Error'.

An initialization step for Dashport then needs to be added into the server file.

After the initialization is added, Dashport is now set up to authenticate. Dashport's authenticate method acts as middleware, so if the framework is Oak, it can be used like below:

After authentication, Dashport will have serialized an ID and manipulated user information based on the developer's defined serializer, and have created a session. In order to get the user information in another route, Dashport's deserialize property can be used as middleware. If the framework is Oak, deserialize will store either the user information or an Error on ctx.locals for the next middleware to access.

In order to end a session, a log out button can be routed to an endpoint that uses Dashport's logOut property as middleware. If the framework is Oak, it can be used like below:

Methods

  • Functionality depends on the server framework that was passed in when instantiating Dashport.

  • initialize is an async middleware function that creates a persistent Dashport object across multiple HTTP requests. For Oak, Dashport takes advantage of the persistent ctx.state and adds a Dashport key to it. This bypasses the need to do any monkey patching.

initialize
authenticate
  • Functionality depends on the server framework that was passed in when instantiating Dashport.

  • authenticate is the async middleware function that powers Dashport. It takes in one argument that is the name of the strategy to be used. Authenticate checks if a session exists. If a session does not exist, it begins the authentication process for the strategy specified. If the authentication is successful, the first serializer added by the developer will be

addSerializer
  • Dashport handles only authentication. If authentication is successful, it will pass the obtained user information to a serializer. It is up to the developer to define serializer functions that specify what to do with user information. User information will be passed in the form of Dashport's defined AuthData interface.

  • addSerializer is a function that takes two arguments. The first argument is the name a developer wants to call their serializer and the second argument is the serializer function. Serializer functions need to

    1. Take in one argument which will be the user data in the form of an object.

    2. Specify what the developer wants to do with the user data (store it in a database, add some info to response object, etc).

    3. Specify how to create a serialized ID.

    4. Return the serialized ID or an Error.

deserialize
  • Functionality depends on the server framework that was passed in when instantiating Dashport.

  • deserialize is an async middleware function that checks if a session exists. If a session exists, it checks if the session IDs match. If they do, it will execute the first deserializer added by the developer and store the user information for the next middleware to use. In Oak, if the deserialization is successful, the user information is stored on ctx.locals. If the deserialization is not successful, an Error will be stored on ctx.locals.

removeDeserializer
  • removeDeserializer is a function that takes one argument. It will remove a deserializer by name that was added.

addStrategy
  • Strategies are the variety of modules that can be imported with Dashport to allow third-party OAuth. They specify the logic for how to get authenticated and authorized to access user information from a third-party OAuth. By following only the few rules listed below, anyone can make a strategy.

  • addStrategy is a function that takes two arguments. The first argument is the name the developer wants to call the strategy. The second argument is a new instance of the strategy with the options passed in. Strategy classes need to

    1. Have a router method that ultimately returns an Error or the user information returned by the third-party OAuth in the form of Dashport's defined AuthData interface. AuthData needs to have a userInfo property in the form of UserProfile and an optional tokenData property in the form of TokenData.

    2. Take in any options that are needed for the specific third-party OAuth to authenticate.

removeStrategy
  • removeStrategy is a function that takes one parameter. It will remove a strategy by name that was added.

logOut
  • Functionality depends on the server framework that was passed in when instantiating Dashport.

  • logOut is an async middleware function that ends a session. If a user logs out and logOut is used, the user will have to reauthenticate. If the framework is Oak, it can be used like below:

AuthData

When a strategy successfully authenticates a user, the information given by the third-party provider should be returned in the form AuthData. The object should have an optional tokenData property and a required userInfo property in the form of UserProfile. This contains the information for the authenticate method to use. The interface for AuthData is as below:

TokenData

Any relevant token data the developer wishes to receive from the third-party OAuth should be stored in an object with the below interface:

UserProfile

Since every OAuth provider returns information in different names and shapes, it is up to each strategy to conform the data returned into Dashport's defined UserProfile interface. This should contain all data the developer wishes to use.

Stretch Features
  • Merge deserialize's functionality into authenticate.

  • Currently only the first serializers and deserializers added are able to be used by Dashport. Add the option to use specific serializers and deserializers by name.

  • Extend the serialization and deserialization process to be able to use multiple serializers and deserializers.

  • Add more strategies.

  • Add support for other server frameworks.

SEWAA.png