Is wrapper for goth library to use with fiber Framework, provides a simple, clean, and idiomatic way to write authentication packages for Go web applications.
Unlike other similar packages, Goth, lets you write OAuth, OAuth2, or any other
protocol providers, as long as they implement the Provider and Session interfaces.
This repo publishes two modules:
github.com/shareed2k/goth_fiber(Fiber v2)github.com/shareed2k/goth_fiber/v2(Fiber v3)
Install the module that matches your Fiber version:
$ go get github.com/shareed2k/goth_fiber
$ go get github.com/shareed2k/goth_fiber/v2
- Amazon
- Apple
- Auth0
- Azure AD
- Battle.net
- Bitbucket
- Box
- Cloud Foundry
- Dailymotion
- Deezer
- Digital Ocean
- Discord
- Dropbox
- Eve Online
- Fitbit
- Gitea
- GitHub
- Gitlab
- Google+ (deprecated)
- Heroku
- InfluxCloud
- Intercom
- Kakao
- Lastfm
- LINE
- Mailru
- Meetup
- MicrosoftOnline
- Naver
- Nextcloud
- OneDrive
- OpenID Connect (auto discovery)
- Paypal
- SalesForce
- Shopify
- Slack
- Soundcloud
- Spotify
- Steam
- Strava
- Stripe
- Tumblr
- Twitch
- Typetalk
- Uber
- VK
- Wepay
- Xero
- Yahoo
- Yammer
- Yandex
See the examples folder for a Fiber v2 example, and the v2/examples folder for a Fiber v3 example.
To run the example either clone the source from GitHub
$ git clone git@github.com/shareed2k/goth_fiber.git
$ go get github.com/shareed2k/goth_fiber
$ cd goth_fiber/examples
$ go get -v
$ go build
$ ./examples
Now open up your browser and go to http://localhost:8088/login/google to see the example.
To actually use the different providers, please make sure you set environment variables. Example given in the examples/main.go file
By default, goth_fiber uses a Session from the gofiber/session package to store session data.
As configured, goth will generate cookies with the following session.Config:
session.Config{
Expiration: 24 * time.Hour,
Storage: memory.New(),
KeyLookup: "cookie:_gothic_session",
CookieDomain: "",
CookiePath: "",
CookieSecure: false,
CookieHTTPOnly: true,
CookieSameSite: "Lax",
KeyGenerator: utils.UUIDv4,
}To tailor these fields for your application, you can override the session handler at startup.
In v1 (Fiber v2), set goth_fiber.SessionStore. In v2 (Fiber v3), set goth_fiber.SessionManager.
The following snippet shows one way to do this:
// optional config
config := session.Config{
Expiration: 30 * time.Minutes,
Storage: sqlite3.New(), // From github.com/gofiber/storage/sqlite3
KeyLookup: "header:session_id",
CookieDomain: "google.com",
CookiePath: "/users",
CookieSecure: os.Getenv("ENVIRONMENT") == "production",
CookieHTTPOnly: true, // Should always be enabled
CookieSameSite: "Lax",
KeyGenerator: utils.UUIDv4,
}
// create session handler
sessions := session.New(config)
goth_fiber.SessionStore = sessionsNote that the session lookup applies to the OAuth callback too. If you point it
at a header (KeyLookup: "header:session_id" above), the browser will not send
that header when the provider redirects back, and CompleteUserAuth will fail
with could not find a matching session for this request. Use a cookie lookup
unless your callback route is genuinely driven by your own client code.
CompleteUserAuth ends the goth session as soon as it returns. That is the
default, and it is why the response to your callback carries an already-expired
_gothic_session cookie: the session it was tracking has served its purpose and
is destroyed.
If you want to keep the session alive after the callback (for example because you read from it again later in the same request), pass the option explicitly:
app.Get("/auth/callback/:provider", func(ctx *fiber.Ctx) error {
user, err := goth_fiber.CompleteUserAuth(ctx, goth_fiber.CompleteUserAuthOptions{
ShouldLogout: false,
})
if err != nil {
return ctx.Status(fiber.StatusBadRequest).SendString(err.Error())
}
return ctx.JSON(user)
})Only the first CompleteUserAuthOptions value is read; any extras are ignored.
Issues always stand a significantly better chance of getting fixed if they are accompanied by a pull request.
Would I love to see more providers? Certainly! Would you love to contribute one? Hopefully, yes!
- Fork it
- Create your feature branch (git checkout -b my-new-feature)
- Write Tests!
- Commit your changes (git commit -am 'Add some feature')
- Push to the branch (git push origin my-new-feature)
- Create new Pull Request