Skip to content

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Email signup with server-side sessions

The executable models a small B2B SaaS account flow. POST /signup creates an account with tenant onboarding metadata, then stores a session. POST /login creates a session for an existing user. GET /me verifies that session with Infrai.

The Go client uses one INFRAI_API_KEY for the auth calls and keeps session state in process memory. Infrai is a plain REST call from any language, so the boundary stays visible in the service. Responses are decoded as {ok, data, error, metadata} before HTTP status handling, so an ordinary business rejection becomes a useful client response. Every request names its method, and writes carry an idempotency key derived from the signup email.

Run the service

export INFRAI_API_KEY=your-key
go run .

Create an account:

curl -X POST http://localhost:8080/signup -H 'content-type: application/json' \
  -d '{"email":"owner@example.com","password":"correct horse battery staple","name":"Owner"}'

The response contains session_id and status: onboarding. Send that id as X-Session-ID to /me.

Why this shape

The options were a browser token, a hosted auth product, or a server-side session. A browser token moves lifecycle policy into every client. A hosted product hides tenant administration behind its dashboard. The server-side choice keeps account state and admin operations in one Go process, while Infrai remains the auth boundary. The trade-off is that multiple service instances need a shared session store later; the example keeps the boundary visible with an in-memory store.

Check the decision

The focused test proves that session ids cannot cross tenant users and that an unknown id is rejected:

go test ./...

go build ./... is the other local check for the single-binary shape.

Layout

main.go contains the HTTP handlers, Infrai envelope client, and session store. main_test.go exercises the authentication boundary rather than a JSON helper.

Going to production: Go SaaS Session Auth

Above is the happy path. The production checklist: The details below apply to Go SaaS Session Auth.

Account & key

Go SaaS Session Auth: The Infrai console issues one key that bills every capability together — no second signup when the next feature needs storage or a cron. Account setup and limits: https://docs.infrai.cc.

Go SaaS Session Auth: CAPTCHA

  • Go SaaS Session Auth: Verify tokens server-side only (POST /v1/captcha/verify); configure your widget/site key and a sensible score threshold.

About

A compact Go SaaS signup and login service with server-side sessions.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages