Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 pprof middleware redirect index page to wrong url #1360

Closed
kurefm opened this issue Jun 3, 2021 · 7 comments · Fixed by #1330 or #1361
Closed

🐛 pprof middleware redirect index page to wrong url #1360

kurefm opened this issue Jun 3, 2021 · 7 comments · Fixed by #1330 or #1361

Comments

@kurefm
Copy link

kurefm commented Jun 3, 2021

Fiber version

v2.11.0

Issue description

The pprof middleware should redirect /debug/pprof to /debug/pprof/, but not redirect /debug/pprof/ to /debug/pprof.

Because of pprof index page use relative herf path, /debug/pprof make sub page (e.g /debug/pprof/allocs) herf link become /debug/allocs

@welcome
Copy link

welcome bot commented Jun 3, 2021

Thanks for opening your first issue here! 🎉 Be sure to follow the issue template! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord

@ReneWerner87
Copy link
Member

#1330

@ReneWerner87
Copy link
Member

@bestgopher you have customized this exact place in the pull request, can you give feedback on this issue

@bestgopher
Copy link
Contributor

@kurefm Could you fix the bug?

@bestgopher
Copy link
Contributor

@ReneWerner87 Sorry for this bug caused by me. I think pprof as a middleware is not a good choice, it should be registered in the router. As a middleware, everyone can access this path, and it is difficult for us to authenticate it.

@ReneWerner87
Copy link
Member

what do you mean that it should be registered in the router and not as middleware ? via middleware a handler is registered and the same possibility exists also only in the router

besides it is better kept as a separate middleware, because it can then be used by anyone who wants or left out.

what do you mean by the last sentence, you can put another middleware in front of the middleware and do any kind of check if a request is allowed to access here or not, that's the advantage of the middlewares and the chaining of them

but more importantly who makes the fix ? @bestgopher or @kurefm ?

@bestgopher
Copy link
Contributor

what do you mean that it should be registered in the router and not as middleware ? via middleware a handler is registered and the same possibility exists also only in the router

besides it is better kept as a separate middleware, because it can then be used by anyone who wants or left out.

what do you mean by the last sentence, you can put another middleware in front of the middleware and do any kind of check if a request is allowed to access here or not, that's the advantage of the middlewares and the chaining of them

but more importantly who makes the fix ? @bestgopher or @kurefm ?

How to achieve this:

        app := fiber.New()

	{
		// pprof
		p := app.Group(
			"/debug/pprof",
			basicauth.New(basicauth.Config{Users: map[string]string{"pprof": "pprof"}},
			),
		)

		p.Get("/", func(ctx *fiber.Ctx) error {
			fasthttpadaptor.NewFastHTTPHandlerFunc(pprof.Index)(ctx.Context())
			return nil
		})

		p.Get("/cmdline", func(ctx *fiber.Ctx) error {
			fasthttpadaptor.NewFastHTTPHandlerFunc(pprof.Cmdline)(ctx.Context())
			return nil
		})
	}
	app.Listen(":3000")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants