Okay so, ordinary Django allows you to simply:
if request.user.is_authenticated:
I want to be able to do the same in Pyrebase. Have the views sort of already know which user has logged in based on the current session without having to sign the user in in all views.
I have tried:
def sign_in(request):
user = firebase.auth().sign_in_with_email_and_password('email', 'password')
user_token = firebase.auth().refresh(user['refreshToken']
request.session['session_id'] = user_token
I noticed this creates a session ID for me. But I don't know how to associate it with the current user and I know it has something to do with the refresh token.
If I don't check authentication, anyone can visit any page of my site without signing in.
I want to render my website name in django templates. Django's own docs on Sites state:
Use it if your single Django installation powers more than one site
and you need to differentiate between those sites in some way.
My django app doesn't. I know I can still use it, but it seems like an overkill. I just want to pull a variable with my website's name (!= domain) in ANY template. I don't want to pass it in views either because that doesn't seem DRY enough.
Writing a custom processor seemed like a simple-enough option, but for some reason these variables aren't available in the .txt emails django-registration sends (while other variables definitely are, so I guess it's not impossible).
TIA
Edit: was asked to include code that doesn't work:
processors.py:
def get_website_name(request):
website_name = 'SomeWebsite'
return {'mysite_name': website_name}
Included successfully in context_processors in settings.py. It works nicely in "regular" templates, but not in emails.
Here's how I'm sending the emails, inside a change_email_view:
msg_plain = render_to_string('email_change_email.txt', context)
msg_html = render_to_string('email_change_email.html', context)
send_mail(
'Email change request',
msg_plain,
'my#email',
[profile.pending_email],
html_message=msg_html,
)
A further problem is that django-regitration further abstracts some of those views away: so when a user registers, wants to reset a password, etc...I don't even have access to the views.
Based on Django custom context_processors in render_to_string method you should pass the request to render_to_string.
msg_plain = render_to_string('email_change_email.txt', context, request=request)
msg_html = render_to_string('email_change_email.html', context, request=request)
I am using python-social-auth and django in my authentication system.
At the moment, when I authenticate with either Facebook or Google, the URL returns with either /#_=_ or /# appended. I understand that these are deliberate but I'd like to remove them.
I've seen a number of javascript solutions for the facebook version, but I'd like to do this from the server side.
I tried to do a basic redirect:
def pre_home(request):
return redirect(reverse('home'))
def home(request):
return render(request, 'core/home.html)
where I directed the auth system to pre_home on completion. I assumed this would strip off the end of the url on redirection to home, however it does not...
I'm trying to use gdata in order to get the contact from my users on my site.
so far I have made a pip install gdata.
Then I added on top of my views.py
CLIENT_ID = 'mythingy' # Provided in the APIs console
CLIENT_SECRET = 'mythingy' # Provided in the APIs console
SCOPE = 'https://www.google.com/m8/feeds'
USER_AGENT = 'dummy-sample'
I have a button on my page that doesn nothing but I would like that if you click it it should ask you for persmission then open a pop up with the gmail contact of the user.
I would like to know how to implement htat.
in my views so far I have:
#login_required
def activate_user(request, activation_key):
user = User.objects.get(username=request.user)
profile = user.get_profile()
auth_token = gdata.gauth.OAuth2Token(client_id=CLIENT_ID,client_secret=CLIENT_SECRET,scope=SCOPE,user_agent=USER_AGENT)
APPLICATION_REDIRECT_URI = 'http://127.0.0.1:8000/oauth2callback'
authorize_url=auth_token.generate_authorize_url(redirect_uri=APPLICATION_REDIRECT_URI)
return render_to_response('registration/activation_complete.html',{'user': user,'profile':profile}, context_instance=RequestContext(request))
But this does nothing.
I haven't touch my urls.py or my settings.py
Thank you
I end up using the javascript API. If anyone needs the code let me know
I have a Django app. When logged in as an admin user, I want to be able to pass a secret parameter in the URL and have the whole site behave as if I were another user.
Let's say I have the URL /my-profile/ which shows the currently logged in user's profile. I want to be able to do something like /my-profile/?__user_id=123 and have the underlying view believe that I am actually the user with ID 123 (thus render that user's profile).
Why do I want that?
Simply because it's much easier to reproduce certain bugs that only appear in a single user's account.
My questions:
What would be the easiest way to implement something like this?
Is there any security concern I should have in mind when doing this? Note that I (obviously) only want to have this feature for admin users, and our admin users have full access to the source code, database, etc. anyway, so it's not really a "backdoor"; it just makes it easier to access a user's account.
I don't have enough reputation to edit or reply yet (I think), but I found that although ionaut's solution worked in simple cases, a more robust solution for me was to use a session variable. That way, even AJAX requests are served correctly without modifying the request URL to include a GET impersonation parameter.
class ImpersonateMiddleware(object):
def process_request(self, request):
if request.user.is_superuser and "__impersonate" in request.GET:
request.session['impersonate_id'] = int(request.GET["__impersonate"])
elif "__unimpersonate" in request.GET:
del request.session['impersonate_id']
if request.user.is_superuser and 'impersonate_id' in request.session:
request.user = User.objects.get(id=request.session['impersonate_id'])
Usage:
log in: http://localhost/?__impersonate=[USERID]
log out (back to admin): http://localhost/?__unimpersonate=True
It looks like quite a few other people have had this problem and have written re-usable apps to do this and at least some are listed on the django packages page for user switching. The most active at time of writing appear to be:
django-hijack puts a "hijack" button in the user list in the admin, along with a bit at the top of page for while you've hijacked an account.
impostor means you can login with username "me as other" and your own password
django-impersonate sets up URLs to start impersonating a user, stop, search etc
I solved this with a simple middleware. It also handles redirects (that is, the GET parameter is preserved during a redirect). Here it is:
class ImpersonateMiddleware(object):
def process_request(self, request):
if request.user.is_superuser and "__impersonate" in request.GET:
request.user = models.User.objects.get(id=int(request.GET["__impersonate"]))
def process_response(self, request, response):
if request.user.is_superuser and "__impersonate" in request.GET:
if isinstance(response, http.HttpResponseRedirect):
location = response["Location"]
if "?" in location:
location += "&"
else:
location += "?"
location += "__impersonate=%s" % request.GET["__impersonate"]
response["Location"] = location
return response
#Charles Offenbacher's answer is great for impersonating users who are not being authenticated via tokens. However, it will not work with clients side apps that use token authentication. To get user impersonation to work with apps using tokens, one has to directly set the HTTP_AUTHORIZATION header in the Impersonate Middleware. My answer basically plagiarizes Charles's answer and adds lines for manually setting said header.
class ImpersonateMiddleware(object):
def process_request(self, request):
if request.user.is_superuser and "__impersonate" in request.GET:
request.session['impersonate_id'] = int(request.GET["__impersonate"])
elif "__unimpersonate" in request.GET:
del request.session['impersonate_id']
if request.user.is_superuser and 'impersonate_id' in request.session:
request.user = User.objects.get(id=request.session['impersonate_id'])
# retrieve user's token
token = Token.objects.get(user=request.user)
# manually set authorization header to user's token as it will be set to that of the admin's (assuming the admin has one, of course)
request.META['HTTP_AUTHORIZATION'] = 'Token {0}'.format(token.key)
i don't see how that is a security hole any more than using su - someuser as root on a a unix machine. root or an django-admin with root/admin access to the database can fake anything if he/she wants to. the risk is only in the django-admin account being cracked at which point the cracker could hide tracks by becoming another user and then faking actions as the user.
yes, it may be called a backdoor, but as ibz says, admins have access to the database anyways. being able to make changes to the database in that light is also a backdoor.
Set up so you have two different host names to the same server. If you are doing it locally, you can connect with 127.0.0.1, or localhost, for example. Your browser will see this as three different sites, and you can be logged in with different users. The same works for your site.
So in addition to www.mysite.com you can set up test.mysite.com, and log in with the user there. I often set up sites (with Plone) so I have both www.mysite.com and admin.mysite.com, and only allow access to the admin pages from there, meaning I can log in to the normal site with the username that has the problems.