It would be very convenient if you could provide a multi arch image on docker hub, so that ARM is supported as well.

Contain a Server-Side Request Forgery (SSRF) via the component /api/baskets/{name}. This vulnerability allows attackers to access network resources and sensitive information via a crafted API request.

https://nvd.nist.gov/vuln/detail/CVE-2023-27163

https://notes.sjtu.edu.cn/s/MUUhEymt7

https://github.com/entr0pie/CVE-2023-27163

we operate the application in kubernetes and want to avoid access to internal ressources via request-baskets, as it can be turned into an open proxy. the most flexible use is probably to provide the ability to allow/deny domains and ip ranges.

example use cases:

• request-baskets --allow-domain example.com --deny-domain dev.example.com
  baskets can only be configured with URLs with example.com
  as domain (e.g. https://api.prod.example.com),
  except URLs pointing to dev.example.com
  (e.g. https://api.dev.example.com)

• request-baskets --deny-domain cluster.local
  baskets can forward any URL except to URLS under the
  cluster.local domain

• request-baskets --deny-address 127.0.0.0/8
  baskets can not forward URLs pointing to the loopback
  interface

• request-baskets --deny-private-address
  shortcut for denying forwards to all addresses designated
  for private use (192.168.0.0/16, 172.16.0.0/12,
  10.0.0.0/8) by the IANA

• request-baskets --allow-address 192.168.1.0/24 --deny-address 192.168.1.1/32 --deny-address 192.168.1.254/32
  only URLs resolving to a class B private net are allowed,
  except 192.168.1.1 and 192.168.1.254

by default, everything is allowed and nothing is denied (just as
before). denials are applied after allowances, so that you
can allow on a broad scale and deny granular.

given that the validation only has to be performed on basket
creation/updates, the resource overhead for domain resolution
should be relatively low.

Could multipart/form-data be handling in a better way? Showing the content is fine, but maybe provide the option to download the files?

How can this be run using docker run, but set a custom token?

I'm trying along the lines of

docker run -p 55555:55555 darklynx/request-baskets request-baskets -token "my-token"

Hi, Mr.Vladimir L. Thank you for sharing. May I ask how to add and set an SSL certificate(Let's encrypt)?

GET https://raw.githubusercontent.com/darklynx/request-baskets/master/doc/api-swagger.yaml
- code: EXTRA_REFERENCE_PROPERTIES
  message: 'Extra JSON Reference properties will be ignored: description'
  path:
    - definitions
    - Request
    - properties
    - headers

you can solve this by wrapping $ref with allOf.

allOf:
  $ref: '#/...'

When setting a forward URL, have an additional setting that allows for the request to complete and pass the response back to the client. I have this minimally setup in my fork, but would probably need to do some work to make it scale.

If this is something you're interested in, I can polish up my fork and submit a PR.

We can provision a basket with BASKET param, but the response config is only in interface/api. To docker containers make senses configure automatically responses to a provisioned basket.

Something like:

request-baskets -basket myapi -response ./response-config.json

Hi!

Currently the site is running off Bootstrap 3. If the site is upgraded to Bootstrap 5+, dark mode could be easily added. In a recent bootstrap update, dark-versions of all the main components have been added, and can be toggled with an attribute on the body element.

I also want to thank you for making such an amazing project.

Hi, and thanks for this software! It's extremely useful.
I'm facing the following problem: I want to put request-baskets under a reverse proxy (e.g. NGINX).
I hold a domain (let's say example.org) and I want to host request-baskets under a subpath of my domain (e.g. https://example.org/baskets/).

I can use a proxy_pass directive with a rewrite so that request-baskets will receive a request similar to 127.0.0.1/web instead of 127.0.0.1/baskets/web. However, it will generate links and redirects such as /web instead of /baskets/web. This breaks the user experience noticeably. I can still host under a subdomain and avoid this problem, but this is not my preferred solution.

Would it be possible to add an option to relativise all URLs or to prepend a custom string to all the endpoints?

Feature Description

It would be great, if a basket could be configured with an expiration time or lifespan. After expiration, the basked would be scheduled for deletion. This could be beneficial to in-memory request storage as automatic clean-up.

The idea is inspired by the 30 minute expiration of https://postb.in/.

Impact on Existing User Workflows

I have not yet checked the code (I can read it, but would not call myself a Gopher) to give an idea where this feature would have impacts and therefore could cause some concerns.
Regarding interfaces, I could imagine to have the possibilities to give a default value for all baskets on the server config, and also pass a basket specific value on the creation request. The expiration time should also appear in the basket info which would add an extra field to the basket response model. Logically, the backward compatible default would be a never value.

Would it be possible to restrict creation of new baskets (and potentially restrict all access to the /api and /web paths) to clients that present the main token? This would potentially make it easier to host Request Baskets on public-facing servers. Right now anyone who visits the domain it is hosted on can immediately create an unlimited number of baskets.

To get somewhat more dynamic responses, i would like to make use of the sprig template functions.

for security reasons env, expandenv, and getHostByName should not be supported.

Similar to provide a defined token it would be great if I could launch request-baskets as container and have a defined basket ready without manual intervention.

Optionally allow for storing and displaying response data like headers and content. I'm using this with the response proxy. Not sure if you want to support something like this, but if so, I can polish up my fork and submit a PR.

Currently, custom responses can be set and matched by method. It would be cool to allow matching by other attributes like path and header.

Please add dockerhub automated build to this repo, so the image is available without custom build

Would be great to configure a password after creating a bucket, replacing the token created with the bucket, to have a shareable password. In addition, it would be nice to be able to share buckets with a link that would not require a password or token.

just saying ;). Also I'm sitting next to you and I like filing public issues.

Installing version v1.2.0 results in the following error, version v1.1.0 works as expected

$ go install github.com/darklynx/request-baskets@latest
go: downloading github.com/darklynx/request-baskets v1.2.0
go: github.com/darklynx/request-baskets@latest: github.com/darklynx/[email protected]: parsing go.mod:
	module declares its path as: darklynx/request-baskets
	        but was required as: github.com/darklynx/request-baskets

Hello @darklynx
I really like your implementation of a request bin.
I'm planning to add a some features that I need, meant mainly for personal use in my own fork but that you may like as well.

Instrumental to this is updating the codebase to use the modern Go Modules (https://blog.golang.org/migrating-to-go-modules) instead of go packages.

I have a PR ready to be submitted if you are interested, the content of which can be seen https://github.com/Jackymancs4-Fork/request-baskets/tree/33895a324ebac4bc2086d7eb8778264a70667225

In that repo I replaced Travis CI with Github Actions worklows, with all tests passing.
If you're willing, this can be another issue.

Anyway, thank you.

After creating a new basket the URL of the basket is shown. Selecting the right text and copying it to the clipboard is a little fiddly. It would be a nice UX enhancement to provide a small copy-to-browser-clipboard icon that uses the html5 clipboard API: https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API
(Like the share-this-basket link on the upper right, but without the token and near to the URL.)

Currently the green GET header displays a truncated GET request only.

In some situations it is necessary to copy+paste the whole request, and currently this is only possible by manually copying the parsed parameters as seen in the "Query Params" box.

A suggestion: why not make the GET header expandable, so that if the user clicks on it, it shows the complete GET request as received by the basket?

When I send a request with a different Host header then the request is logged successfully but the Host is missing.

curl -H "Host: example.com" https://rbaskets.in/3vgdn65

Shows:

Testing with webhooks.site the host header is listed:

This prevents debugging host-related issues.