pastebinit: wrong protocol, wrong url

[ThomasWaldmann]

when pasting to a https bepasty (with nginx reverse proxy doing the https), pastebinit shows a http link after pasting. also it shows a wrong (generic, upload) url instead of the specific download url.

[ThomasWaldmann]

had a quick look, but couldn't find the culprit, neither in pastebinit, nor in bepasty.

[ThomasWaldmann]

Still does not work:

$ echo "test" | pastebinit 
http://paste.thinkmo.de/+upload
# ^ should be https ... and also it should not show /+upload, but the specific pastebin result url

$ pastebinit -v
pastebinit v1.5

[ThomasWaldmann]

Our docs for pastebinit usage/configuration with bepasty:

https://bepasty-server.readthedocs.io/en/latest/user-cli.html#pastebinit

[drasch]

Did anyone ever figure this out? I'm running into the same thing with pastebinit and bepasty on FreedomBox. I'm also using nginx to do the reverse proxy. Everything seems okay on the browser side.

[drasch]

I kept digging over here, and found there we're getting an error on the bepasty flask side:

Looks like this commit fixed it: 2fe9f8f

[2021-03-05 09:26:25,976] ERROR in app: Exception on /+upload [POST]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/flask/app.py", line 2292, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1815, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1718, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/flask/_compat.py", line 35, in reraise
    raise value
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1813, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1799, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/lib/python3/dist-packages/flask/views.py", line 88, in view
    return self.dispatch_request(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/flask/views.py", line 158, in dispatch_request
    return meth(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/bepasty/views/upload.py", line 55, in post
    maxtime = get_maxlife(request.form, underscore=False)
  File "/usr/lib/python3/dist-packages/bepasty/utils/date_funcs.py", line 14, in get_maxlife
    return time_unit_to_sec(value, unit)
  File "/usr/lib/python3/dist-packages/bepasty/utils/date_funcs.py", line 34, in time_unit_to_sec
    secs = units[unit] * value if units[unit] > 0 else units[unit]
KeyError: 'MONTH'

[ThomasWaldmann]

Yes, if you do not have that commit in the running code, it will cause this exception if a upload post request is received and misses the maxlife-related entries (which is likely the case for a lot of clients without special support for that).

[drasch]

On my Freedombox (Debian-based) running 0.5.0-2~bpo10+1 line 30 was MONTHS while the unit_default was being set to MONTH. Now that I've changed line 9 to be MONTHS it's working (and restarting uwsgi systemctl restart uwsgi).

But, I'm still getting urls with http instead of https.

my config:

[pastebin]                                 
basename = https://libre.example.com 
regexp = https://libre.example.com/bepasty/  
                                           
[format]                                   
content = text                             
title = filename                           
format = contenttype                       
page = page                                
password = token                           
                                           
[defaults]                                 
page = +upload                             

[ThomasWaldmann]

So most of the URL is correct, just the protocol still wrong?

Wrong protocol can be due to reverse proxy, because the wsgi app is unaware of https.

[drasch]

Great point, and I'm now testing with curl and seeing the right output.
I'll continue checking pastebinit . It looks like bepastey is returning the right stuff when tested with curl.

INPUT:

curl -v --data 'text=test&filename=test.txt&contenttype=&token=SECRET' https://libre.example.com/bepasty/+upload

OUTPUT:

...
< HTTP/2 302 
< server: nginx/1.15.12
< date: Fri, 05 Mar 2021 14:53:29 GMT
< content-type: text/html; charset=utf-8
< content-length: 259
< location: https://libre.example.com/bepasty/J4RJQFoR#test.txt
< strict-transport-security: max-age=31536000; includeSubDomains
< 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
* Connection #0 to host libre.example.com left intact
<p>You should be redirected automatically to target URL: <a href="/bepasty/J4RJQFoR#test.txt">/bepasty/J4RJQFoR#test.txt</a>.  If not click the link.

[ThomasWaldmann]

https://werkzeug.palletsprojects.com/en/1.0.x/middleware/proxy_fix/ try that for the http -> https fix!

[ThomasWaldmann]

If you succeed, a small pull request for our docs with a snippet and linking to that docs would be nice. This is a common problem for reverse proxy users.

[drasch]

Will do! Thanks for the quick response and help!

…

On Fri, Mar 5, 2021 at 10:05 AM TW ***@***.***> wrote: If you succeed, a small pull request for our docs with a snippet and linking to that docs would be nice. This is a common problem for reverse proxy users. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABWDJL6VFQMLTHSYGQUBTLTCDXK7ANCNFSM4AXFKWGA> .

-- David Rasch rasch@raschnet.com