I have a series of different domain names that I would like to all point (via URL forwarding from my domain host) to a google app engine application that reads what the forwarding URL is. So if the domain typed in was original XYZ.com, then when I am forwarded to my application, I can return what that original domain name was. I'm using the python variant. How best can I do this without coding for each and every variant?
Generally, the target of a 301/302 redirect can't determine what URL issued the redirect. If the user is redirected by client-side code, the referring page should be present in the "Referer" request header. For server-side redirects, I don't believe it's standard for user agents to populate (or override) the Referer header.
If you want to point multiple domains to your App Engine app, try configuring them as custom domains rather than forwards. With this route, the custom domain would stay in the user's address bar, and you can simply check the host header to see which custom domain the visitor is using.
If by forwarding you mean HTTP redirection, you can check the Referer header.
If you mean DNS resolving (e.g. distinguishing between your application being invoked via your own domain and .appspot.com one), there is SERVER_NAME environment variable (os.environ["SERVER_NAME"]) that stores the domain (e.g. www.example.com) used to issue the request.
If you are using a javascript redirect, that you can just check the referrer:
http://en.wikipedia.org/wiki/HTTP_referrer
but this is not a 100% solution.
If you have multiple domains parked on one appengine instance and you just want to know which one the user is viewing, you can check the host name in the request object.
Related
According to the Flask Documentation, I should be able to set a cookie with a domain path for domains besides my own like this:
resp = make_request(render_template(index.html))
resp.set_cookie('cookiekey', 'cookievalue', domain='notmydomain.example.com')
I was able to set cookies for my domain with just
resp.set_cookie('cookiekey', 'cookievalue')
and they were accepted by the browser (Chrome). However, when I try to set the domain, they don't appear in the browser. Further, testing with postman reveals that the Set-Cookie headers are sent, and are correct.
Does this mean the browser is simply ignoring my request, and if so how can I get it to accept my Set-Cookie headers?
TL;DR: you can't set cookies for domains completely separate from your current domain.
Setting cookies for domains outside of your control would pose an immense security risk. The domain attribute only allows you to set cookies for either the whole domain or a subdomain. This is how, for example, a system can log you in via a subdomain such as "auth.example.org" then redirect you to "example.org".
In practice, "unified" sign-in systems are complicated: challenges are used and data might be exchanged through a backend, not relying on the browser to properly allow other subdomains to access the original cookie.
I'm wanting to implement SECURE_HSTS_SECONDS to my Django settings for extra security - however the warning from the Django docs is making me abit scared so I want some clarification. Here is what is says:
SECURE_HSTS_SECONDS
Default: 0
If set to a non-zero integer value, the SecurityMiddleware sets the HTTP Strict Transport Security header on all responses that do not
already have it.
Warning:
Setting this incorrectly can irreversibly (for some time) break your site. Read the HTTP Strict Transport Security documentation first.
What has to happen for it to "break my site"? I read the HTTP Strict Transport Security documentation first and it didn't make it any clearer.
HTTP Strict Transport Security
HTTP Strict Transport Security lets a web site inform the browser that
it should never load the site using HTTP and should automatically
convert all attempts to access the site using HTTP to HTTPS requests
instead. It consists in one HTTP header, Strict-Transport-Security,
sent back by the server with the resource.
In other words, if you set the value of SECURE_HSTS_SECONDS to e.g. 518400 (6 days) your web server will inform your client's browser the first time he visits your site to exclusively access your website over https in the future. This applies to the entire defined period. If for any reason you no longer provide access to your website over https the browser couldn't access your services anymore.
Therefore, you should initially set this variable to a low value of like 60s and make sure that everything works as expected, otherwise you could prevent yourself and your client from visiting your site.
Browsers properly respecting the HSTS header will refuse to allow
users to bypass warnings and connect to a site with an expired,
self-signed, or otherwise invalid SSL certificate. If you use HSTS,
make sure your certificates are in good shape and stay that way!
Source
I am using Facebook's Tornado web engine for Python for a project I'm doing and was planning on implementing the XSRF protection, but it left me a little confused.
On a typical request it sets an "_xsrf" cookie to the user's browser if it's not found and then matches that with the value embedded in an HTML form value the browser has sent with the request.
Well let's say an attacker did something like this:
<img src="blah.com/transfer_money?account=0098&destination=0099&_xsrf=
(whatever the client's cookie contains)" title="cool image" />
What's to prevent the attacker from using the cookie outright? As far as I can tell the cookies used for XSRF are not "secure" both from the check_xsrf_cookie method and the xsrf_token method that actually generates the XSRF token. Am I missing something...?
If I understand you correctly, you are asking what prevents attacker from accessing user's cookie in given domain.
Well, the answer is: browser security policy. The script from one domain cannot access cookie from other domain (most of the time). More details here: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
This can be circumvented by using XSS (Cross-Site Scripting) attack: injecting the script directly into the source of attacked page. Another approach is to break the client application (browser).
However, most of the time it is not possible for the attacker to retrieve user's cookie from other domain. Additional level of security would be to associate specific CSRF (or "XSRF") token with specific user (and to check it during validation).
title might be a bit of a misnomer.
I have two subdomains setup in a web application, one for the application frontend at www. (which is using a loose PHP router coupled with backbone, require, and jquery for UI) and a data tier setup at data. (built entire in python utilizing Werkzeug)
We decided to go to this kind of architecture since at some point mobile app will be integrated into the equation, and they can just as easily send HTTP connections to the data subdomain. The data subdomain renders all its responses in JSON, which the JS frontend expects universally as a response be it a valid query response or an error.
This feels like the most organized arrangement I've ever had on a project, until Facebook connect appeared on the manifesto.
Ideally, I'd like to keep as much of the 'action' of the site behind the scenes on the data subdomain, especially authentication stuff, so that the logic is available to the phones and mobile devices as well down the line if need be. Looking into the facebook docs, it appears however that the browser and its session object are critical components in their OAuth flow.
User authentication and app authorization are handled at the same time
by redirecting the user to our OAuth Dialog. When invoking this
dialog, you must pass in your app id that is generated when you create
your application in our Developer App (the client_id parameter) and
the URL that the user's browser will be redirected back to once app
authorization is completed (the redirect_uri parameter). The
redirect_uri must be in the path of the Site URL you specify in
Website section of the Summary tab in the Developer App. Note, your
redirect_uri can not be a redirector.
I've done this before in PHP and am familiar with the process, and it's a trivial matter of about 3 header redirects when the logic in question has direct access to the browser. My problem is that the way our new app is structured, all the business logic is sequestered on the other subdomain. What are my options to simulate the redirect? can I have the python subdomain send the HTTP data, receiving it from the www domain using CURL like all the other requests? Can I return a json object to the user's browser that instructs on doing the redirects? Will Facebook even accept requests from a data subdomain, whose redirect_uri is at subdomain www? I find that last sentence in the quoted section probably discounts that as a possibility, but I've looked through their docs and it doesn't explicity say that this would be treated as a violation.
Has anyone had any experience setting up something like this with Facebook with a similar architecture? Perhaps I should just fold and put the FB login logic directly into PHP and handle it there.
Thanks!
Can anyone explain me steps using openid library which is mentioned here.
I have import all package of janrain openid in my programe but I cant understand actual flow of code.
The process should basically follow this plan:
Add an OpenID login field somewhere on your site. When an OpenID is entered in that field and the form is submitted, it should make a request to the your site which includes that OpenID URL.
First, the application should instantiate a Consumer with a session for per-user state and store for shared state. using the store of choice.
Next, the application should call the 'begin' method on the Consumer instance. This method takes the OpenID URL. The begin method returns an AuthRequest object.
Next, the application should call the redirectURL method on the AuthRequest object. The parameter return_to is the URL that the OpenID server will send the user back to after attempting to verify his or her identity. The realm parameter is the URL (or URL pattern) that identifies your web site to the user when he or she is authorizing it. Send a redirect to the resulting URL to the user's browser.
That's the first half of the authentication process. The second half of the process is done after the user's OpenID Provider sends the user's browser a redirect back to your site to complete their login.
When that happens, the user will contact your site at the URL given as the return_to URL to the redirectURL call made above. The request will have several query parameters added to the URL by the OpenID provider as the information necessary to finish the request.
Get an Consumer instance with the same session and store as before and call its complete method, passing in all the received query arguments.
There are multiple possible return types possible from that method. These indicate the whether or not the login was successful, and include any additional information appropriate for their type.
web.py includes a webopenid module that implements a complete, if basic, OpenID authentication system using the Janrain. Using the included host class, you can add OpenID-backed authentication to your project. To actually pull interesting data from the OpenID provider, though, you'll need to add AX and SReg request/response handling.