I'm wondering if the always on feature would be similar to having a static VIP? if so then I can directly edit zone file to go that address instead of via the ghs.google.com dns system. Hopefully this should be better in regards to filtering/censorship etc.
No. The always-on feature affects the provision of application instances on the backend; it has no effect on the routing of requests from the frontend to your app.
Related
Having multiple languages to deploy under appengine; I wonder if some kind of private approach could be applied; in order to have it all resides only under a single domain
For example, given xyz.com domain setup as wildcard; having a default service, services svc1 and svc2; and a dispatch.yaml mapping */svc1/* to svc1 service and */svc2* to svc2 service; how to :
hide all the *.appspot domain ?
hide the automatic setup of svc1.xyz.com and svc2.xyz.com ?
It could be easy for a given service to check the host and redirect to the desired one; but it would have to be done for every services; feels like there a better way
It feels a bit messy to have all those auto enopoints opened and unused, the idea would be to have it all under xyz.com/
-
There is no way of hiding all the routes of the .appspot domain. As you probably are aware the dispatch.yaml, only works as a redirect. Probably, you cannot just disable the default domain, since there are a lot of tools like Cloud Tasks, Cron Jobs etc.. that uses that default domain, hitting those endopoints.
As for the second question, you cannot hide them, but in case you don't need them, you can overwrite them in the dispatch.yaml to point to some custom made "not found" page.
Is it possible to have multiple user profiles—with separate cookies, history, local storage, etc.—running at the same time in one CEF (Chromium Embedded Framework) instance? The goal is to allow multiple browsing "sessions" side-by-side in one window (it's actually an OpenGL app).
There are two possible solutions I've looked into, each with its own problems:
Using CefCookieManager
This is possible to do for just cookies by creating multiple CefCookieManagers. However, there does not seem to be similar API for history and local storage, which are now still shared.
Using CefSettings::cache_path
CefSettings settings;
CefString(&settings.cache_path).FromASCII("C:\\CefCache");
CefInitialize(args, settings, app, nullptr);
The problem here is that CefSettings is associated with the global CEF instance rather than with each browser/client.
Is there a way to do this that I have not discovered?
If it's only about cookies and local storage, and you host content using custom scheme handler or request interception, then you could use different domains/subdomains for each profile. See this topic for reference: http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=11695 .
Regarding history, you could implement history on your own by using the OnBeforeBrowse callback.
In the topic referenced above it is also mentioned that it's technically possible to specify a different cache path per CefRequestContext (can be provided during browser creation). So working on a patch for CEF may be another option.
EDIT: CEF revision 2040 adds support for complete isolation of storage and permissions per request context, see comment #7 in Issue 1044: https://code.google.com/p/chromiumembedded/issues/detail?id=1044#c7
And is there a way to send a request directly to that server?
Actually there is a way and it can be useful for pushing new data out to all instances of an application.
from google.appengine.api import modules
instance_id = modules.get_current_instance_id()
ref: GAE Modules Docs
For what purpose?
If you want to test different versions, you can use traffic splitting https://developers.google.com/appengine/docs/adminconsole/trafficsplitting
That is different versions though, and not a specific instance.
No there isn't.
Usually when someone asks something like this, they're headed in the wrong direction on app engine. Frontend servers get started and shutdown all the time. If you are designing anything that relies on a particular instance, you're doing it wrong. You need to design requests that work no matter what instance they hit.
Consider using backends if you must do that.
I use Python and a datetime stamp to identify an instance. This instance id is set by appengine_config.py. To signal other instances I use a flag in memcache, which is checked by the __init__ of my webapp2 request handler.
I use signals to other instances to flush the jinja environment and reload dynamic python code, because I could not find another way.
Here is an example of a memcache flag; signalling to reload all dynamic modules, which had been set by instance id: '2012-12-26 16:39:50.072000'
{ u'_all': { u'dyn_reloads_dt': datetime.datetime(2012, 12, 26, 16, 39, 59, 120000),
u'setter_instance': '2012-12-26 16:39:50.072000'}}
And I starred the feature request from : Ibrahim Arief
With the advent of Modules, you can get the current instance id in a more elegant way:
ModulesServiceFactory.getModulesService().getCurrentInstanceId()
Also, according to this doc, you can route requests specifically to a particular instance by using a URL like
http://instance.version.module.app-id.appspot.com
Note that you need to replace the dot with -dot- to suppress the SSL certificate warning your web client may be complaining about:
http://instance-dot-version-dot-module-dot-app-id.appspot.com
A couple of our clients want to know - looking at some posts about there is inconsistent information.
http://code.google.com/p/googleappengine/issues/detail?id=1144
The answer is "No", for now and long after.
of cz google support his service in china,
but not china gov.
appspot is blocked by a big firewall around china.
by the way, it works when Obama visitting china.
Based on tests I conducted it appears that App Engine itself is not blocked in China, but the appspot.com domain is. So if you can use your own domain then App Engine should work fine for you.
In fact, if you use yourapp.appsp0t.com (with a zero instead of an o) then it seems to work as well at the moment, although I would not really recommend relying on this work-around in the long run; it opens your app and your users to Man in the Middle (MITM) attacks from whoever runs appsp0t.com.
Here are some tools you can use to check availability and performance from China:
http://www.greatfirewallofchina.org/
http://www.websitepulse.com/help/testtools.china-test.html
http://www.dotcom-monitor.com/WebTools/website-speed-test.aspx
Not directly, since Google DNS server is blocked by 'Great Firewall', therefore one cannot reach myapp.appspot.com within China.
However, you can work around by setting up a reverse-proxy server, which redirects myapp.com to myapp.appspot.com.
What about using custom domain name?
This will get around the DNS resolution. But is the google IP address range allocated for appengine blocked by china? If so, you then you have to use the reverse proxy solution.
I'm working on building a Silverlight application whereas we want to be able to have a client hit a url like:
http://{client}.domain.com/
and login, where the {client} part is their business name. so for example, google's would be:
http://google.domain.com/
What I was wondering was if anyone has been able, in silverlight, to be able to use this subdomain model to make decisions on the call to the web server so that you can switch to a specific database to run a query? Unfortunately, it's something that is quite necessary for the project, as we are trying to make it easy for their employees to get their company specific information for our software.
Wouldn't it work to put the service on a specific subdomain itself, such as wcf.example.com, and then setup a cross domain policy file on the service to allow it to access it?
As long as this would work you could just load the silverlight in the proper subdomain and then pass that subdomain to your service and let it do its thing.
Some examples of this below:
Silverlight Cross Domain Services
Silverlight Cross Domain Policy Helpers
On the server side you can check the HTTP 1.1 Host header to see how the user came to your server and do the necessary customization based on that.
I think you cannot do this with Silverlight alone, I know you cannot do this without problems with Javascript, Ajax etc. . That is because a sub domain is - for security reasons - treated otherwise than a sub-page by the browsers.
What about the following idea: Insert a rewrite rule to your web server software. So if http://google.domain.com is called, the web server itself rewrites the URL to something like http://www.domain.com/google/ (or better: http://www.domain.com/customers/google/). Would that help?
Georgi:
That would help if it would be static, but alas, it's going to all be dynamic. My hope was to have 1x deployment for the application, and to use the http://google.domain.com/ idea to switch to the correct database for the user. I recall doing this once when we built an asp.net website, using the domain context to figure out what skin to use, etc.
Ates: Can you explain more about what you are saying... sounds like you are close to what I am trying to come up with. Have you seen such a tutorial for this?
The only other way I have come up with to make this work is to have a metabase that when the user logs in, it will switch them to the appropriate database as required... was just thinking as well that telling Client x to hit:
http://ClientX.domain.com/ would have been sweeter than saying to hit http://www.domain.com/ and login. It seemed as if they were to hit their name, and to show it personalized for them right from the login screen would have been much more appealing for the client base.
#Richard B: No, I can't think of any such tutorial that I've seen before. I'll try to be more verbose.
The server-side approach in more detail:
Direct *.example.com to the same IP in your DNS settings.
The backend app that handles login checks the Host HTTP header (e.g. the "HTTP_HOST" server variable in some platforms). That would contain the exact subdomain.example.com that the client used for reaching your server. Extract the subdomain part and continue...
There can also be a client-side-only approach. I don't know much about Silverlight but I'm assuming that you should be able to interface Silverlight with JavaScript. You could read document.location with JavaScript and pass it to your Silverlight applet, whereon further data fetching etc. logic would rely on the subdomain that was passed in by JavaScript.
#Ates:
That is what we did when we wrote the ASP.Net system... we pushed a slew of *.example.com hosts against the web server, and handled using the HTTP headers. The hold-up comes when dealing with WCF pushing the info between the client and the server... it can only exist in one domain...
So, for example, when you have {client}.example.com and {sandbox}.example.com, the WCF service can't be registered to both. It also cannot be registered to just *.example.com or example.com, so that's where the catch 22 is coming in at. everything else I have the prior knowledge of handling.
I recall a method by which an application can "spoof" another domain name in certain instances. I take it in this case, I would need to do such a configuration? Much to research yet I believe.