Skip to content
This repository has been archived by the owner on May 19, 2023. It is now read-only.

Header key always authenticates #86

Closed
DavZim opened this issue Nov 14, 2022 · 7 comments
Closed

Header key always authenticates #86

DavZim opened this issue Nov 14, 2022 · 7 comments
Labels
👍 Accepting PR 🤔 Question Further information is requested

Comments

@DavZim
Copy link
Contributor

DavZim commented Nov 14, 2022

I am new to GO and gofiber, so please forgive me when this is trivial or wrong.

I am using keyauth to have authentication via an API key in the header but it seems that keyauth does not accept the key - even worse, it seems to accept all keys.

For example, when I want to secure the API with the key CORRECT-KEY, I would use the following

package main

import (
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/keyauth/v2"
)

func main() {
	app := fiber.New()
	app.Use(keyauth.New(keyauth.Config{
		KeyLookup:  "header:key",
		ContextKey: "CORRECT-KEY",
	}))

	app.Get("/ping", func(c *fiber.Ctx) error {
		return c.SendString("OK")
	})
	app.Listen(":3000")
}

When I run the following commands from curl, I get the following results

# expected result as no API Key was specified
❯ curl localhost:3000/ping
missing or malformed API Key

# expected result 2: API key was specified and is correct
❯ curl -H "key: CORRECT-KEY" localhost:3000/ping                                                                                                                                
OK

# This is the unexpected part: the wrong key is specified, yet the result is still returned.
❯ curl -H "key: CLEARLY A WRONG KEY" localhost:3000/ping                                                                                                                        
OK

Did I misunderstood the way keyauth is supposed to be used (ie I misconfigured it) or is this a bug?

The same thing happens when I use "cookie:access_token", it also accepts all tokens/keys.

@DavZim
Copy link
Contributor Author

DavZim commented Nov 14, 2022

One way to navigate around this is to specify the Validator in the keyauth.Config like so:

Validator: func(c *fiber.Ctx, key string) (bool, error) {
	return key == "CORRECT-KEY", nil
},

but that hardcodes the password in the function (what is then the ContextKey used for?). This is what I would have expected to be the default behavior.
Let me know if I am missing something or don't understand the inner logic.

@ReneWerner87
Copy link
Member

Other example https://github.com/gofiber/recipes/blob/8c1ea524846b14753a9e2a9f9eda040f25f7330c/fiber-envoy-extauthz/authz/main.go

@jozsefsallai can you support here

@DavZim
Copy link
Contributor Author

DavZim commented Nov 15, 2022

Thank you for pointing me to the example.
Is it ok if I send a PR to keyauth that updates the Readme to include a Validator function to show how to fully use it?

@ReneWerner87
Copy link
Member

sure

@ReneWerner87 ReneWerner87 added 🤔 Question Further information is requested 👍 Accepting PR labels Nov 15, 2022
@jozsefsallai
Copy link
Member

what is then the ContextKey used for?

@DavZim ContextKey is used for storing a valid key in the local parameter map of the request's context. You can use ctx.Locals(contextKey) in a middleware or request handler to access the value of the key. Note that this will only store the key in the locals if a valid one was supplied by the client.

More on request context locals: https://docs.gofiber.io/api/ctx#locals

@jozsefsallai
Copy link
Member

jozsefsallai commented Nov 16, 2022

Also @ReneWerner87, I think Validator should be a required option. Fiber should return an error (or at least print out a warning) if you don't specify a custom validator function. Would make things less confusing.

@gaby
Copy link
Member

gaby commented Jan 15, 2023

@ReneWerner87 I think this can be closed now that #90 was merged.

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
👍 Accepting PR 🤔 Question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants