I'm trying to access a Django page through a Facebook App (iframe) I made using fb.py on DreamHost and I keep getting an internal server error.
Looking in the error logs, this is what I see:
ModSecurity: Output filter: Failed to read bucket (rc 104): Connection reset by peer
I think it just has to do with the POST request. Somebody else asked about this error on a number of forums almost a year ago, to no avail:
ModSecurity: Output filter: Failed to read bucket (rc 104): Connection reset by peer
All I could find searching was this at http://www.modsecurity.org:
"When mod_security denies such a request, it sends an error bucket with e.g. code 403 down the output filter chain, leaving r->status as is (e.g. 500)."
Any ideas? Thanks!
Have you implemented CSRF protection as per https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax ?
Note to cross-check with the version of Django you are using.
So I've spent way too much time trying to figure this out. I've settled on a (slightly shitty) work-around: add {% csrf_token %} to any place in your template (I'm assuming you passed in the context_instance=RequestContext(request) argument to your render_to_response or whatever).
I think what is happening is that the cookie doesn't actually get set (this can be confirmed through inspecting the cookies in any browser's development tools). Adding the above code to your template forces this. I have a feeling that this may be remedied in later versions of Django, and it seems as though there are obvious fixes for 1.4+ (e.g., see here). Unfortunately dreamhost has stuck us with 1.2.3, so we need to make do.
Related
I followed the steps in this tutorial to enable SSO with Azure Active Directory for the admin portion (to start) of my Django app:
https://django-microsoft-auth.readthedocs.io/en/latest/usage.html
Navigating to /admin yields this page, which is good:
Clicking Microsoft brings up this new window:
The important error seems to be:
AADSTS90102: 'redirect_uri' value must be a valid absolute URI.
In this window, I used the browser console and found that a GET request was being made like this:
https://login.microsoftonline.com/50ce...90ac7/oauth2/v2.0/authorize?response_type=code&client_id=f4...27&redirect_uri=https,https://example.org/microsoft/auth-callback/&s...
Note the redirect_uri=https,https://.... It seems like that leading "https," is superfluous and is causing the problem. Any ideas where that could be coming from?
In my Azure app, the redirect URI is set to https://example.org/microsoft/auth-callback/:
I'm using Python 3.9.6, Django 3.2, django-microsoft-auth 2.4.0, NGINX 1.18.0, uvicorn 0.14.0
I've searched for help on this and haven't found anything relevant to my situation. Thanks in advance!
Based on the SO Thread Reference.
Use http as the redirect URI instead of https to resolve the issue in most cases.
use
http://localhost:8080/microsoft/auth-callback/
Instead of
https://localhost:8080/microsoft/auth-callback/
If there is a option,
Use localhost:8080 into the table django_site
Reference SO Thread: django-microsoft-auth : The provided value for the input parameter 'redirect_uri' is not valid
As you think, the first https is superfluous, you just need to delete it.
https://login.microsoftonline.com/50ce...90ac7/oauth2/v2.0/authorize?response_type=code&client_id=f4...27&redirect_uri=https://example.org/microsoft/auth-callback/&s...
By the way, I think there is no problem with the redirect_uri you set in the Azure portal.
I guess it is a problem of the redirecting URL. The example URL is coming from django site table. So first of all you need to enable the site:
#in settings.py
SITE_ID = 1
Afterwards you can go to the admin interface and set the url of the site to the correct domain. From my experience I know that it won't work without that.
I am using pywebpush 1.4.0 library to push Web Notifications from Django backend. The keys that I'm using were obtained from https://web-push-codelab.glitch.me/. Subscription seems to working fine. Moreover, I tested this on Firefox and it is working fine there.
I receive the following error server side while pushing on Chrome:
Push failed: <Response [400]>: <HTML>
<HEAD>
<TITLE>UnauthorizedRegistration</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>UnauthorizedRegistration</H1>
<H2>Error 400</H2>
</BODY>
</HTML>
The strange part is that my backend controls 3 domains and push is working fine even for Chrome on one domain and not working on others. I ruled out the following possible issues:
Improper Private and Public Key pairs as it is working fine on Firefox
Outdated pywebpush library as on one domain on Chrome it is working fine
Few answers (Chrome Web Notification Push Unauthorized Registration exception) pointed out to update the py-vapid version installed by pywebpush but it's version is already py-vapid==1.3.0
The only possibility I see is if Chrome doesn't allow push notifications on different domains from the same backend. Is anyone aware of such a limitation or could help me with any other pointers here?
Note: I'm using different keys for all the three domains.
Here is the code I'm using to push:
from pywebpush import webpush
webpush(subscription_info,
data,
vapid_private_key=vapid_private_key,
vapid_claims={"sub": "mailto:xyz#example.com"})
The subscription_info is the json as received while subscribing a user, vapid_private_key is the corresponding private key.
The FAQ lists the following reasons for your error (quote):
If you fail to define an Authorization header in the request to FCM.
Your application key used to subscribe the user doesn't match the key used to sign the Authorization header.
The expiration is invalid in your JWT, i.e. the expiration exceeds 24 hours or the JWT has expired.
The JWT is malformed or has invalid values
It also states the requirement of adding a applicationServerKey to the request, and that this is not mandated in Firefox. Your issue may lie here: are you sure that the vapid_private_key variable refers to a correct private key for each domain? It might be that it's actual consistently the key of your working domain.
It might be easier to find some potential errors if we had more of the code you used. Chrome just needs a single key per server, but should be able to handle several different servers subscribing.
I am fairly new to python/django. But my code has been running perfectly fine. And now I am suddenly getting this error. My code is about file upload.
I have added {% csrf_token %} in the view.
The "django.middleware.csrf.CsrfViewMiddleware" is in the settings file.
And I am returning the response with the render () function.
Is there anything that I need to check on? I have been running/testing this code for a week or so and now suddenly this error is popping up. I am not sure how to debug it.
Thanks in advance,
Vrunda
Normally '403 Forbidden' errors occur for two main reasons:
In case of a Cross Site Request Forgery (which is probably not your case)
Programming error, CSRF token is not included with a POST form
Here is the Doc
Also, as you asked for possible approaches, see this duplicate: https://stackoverflow.com/a/31618511/7692463
Hope it helps!
I have create a webproject Web2Py and would like user to access the pages on normal http:// instaed of http://.
Each time I type http://domain.pythonanywhere.com et redirect me to http://domain.pythonanywhere.com.
It taces 0.5 sec. to do the SSL check and I would like to avoid that.
This was as default:
## if SSL/HTTPS is properly configured and you want all HTTP requests to
## be redirected to HTTPS, uncomment the line below:
# request.requires_https()
PythonAnywhere dev here: that looks like a bug on our side. We "pin" HTTPS for our own site, so that people always go to https://www.pythonanywhere.com/, but it looks like that might have leaked over to customer sites.
Just for clarity -- if someone goes to http://yourusername.pythonanywhere.com/ then we won't initially force it to go to the https site -- they'll get the http one. But if they then go to https://yourusername.pythonanywhere.com, then their browser will remember that they have visited the https domain, so all future requests will redirect there.
That's actually generally good practice (it works around a number of security problems) but we shouldn't be forcing it on people.
[UPDATE] the bug is now fixed, many thanks to boje for pointing us at it :-) One caveat -- if you've ever visited your site over HTTPS before we applied the fix, then you'll still be forced to HTTPS. You need to clear your browser history to see the new unpinned behaviour.
I had an issue let http:// redirect to https:// And I found google group post on here. The following code maybe give you some ideas on your problem, Under db.py add:
############ FORCED SSL #############
from gluon.settings import global_settings
if global_settings.cronjob:
print 'Running as shell script.'
elif not request.is_https:
redirect(URL(scheme='https', args=request.args, vars=request.vars))
session.secure()
#####################################
Is there some way or using the bulkloader.py dump and restore functionality without authentication?
I have tried using:
- url: /remote_api
script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py
without the login-parameter, but login still seems to be required.
I still get
[ERROR ] Exception during authentication
I struggled with this for 6 hours yesterday, without any solution.
And yes, I have tried GAEBAR. It failed, however when it got to entities that contain up to 1MB (the maximum pr. entity) Blobs.
So, I am looking to dump (and restore) for backup-purposes mainly.
remote_api, which the bulkloader uses, is written to deliberately require authentication, even if you omit the relevant clause in app.yaml. You can override it if you really want, but it's an incredibly bad idea - it would allow any anonymous user to do practically anything they liked to your app!