They seem to go against the advice
You may be tempted to store the chosen
locale in a session or a cookie. Do
not do so. The locale should be
transparent and a part of the URL.
from the official Rails I18n guide
I tried seeing if they set a cookie for the locale, and it seems like they don't.
So how do they do it and why they chose not to use URLs for different languages, like http://github.com/en/foo, http://github.com/fr/foo, etc. ?
It uses the _gh_sess cookie to store that information.
Multiple URLS are sometimes avoided because they create something looking a lot like duplicate content for search engines. This can deplete your Google Karma and lead to poor SEO performance.
Related
after reading all the threads on stackoverflow and other platforms, I still wasn't able to find an answer, which satisfies me.
The task:
I want to create a single page application (SPA) which receives data from a REST API. In this SPA, NO authentication should be used. It's a public site.
But the REST API should only be accessible from people who loaded the SPA from my webserver.
I assume this is only solvable with something on server side like sessions, cookies etc. - otherwise I'm open for your suggestions, solutions etc.
Thx in advance!
There's no reasonably easy way to do this. You can easily prevent other domains (in browsers) from accessing a an API on your domain (via CORS), but it's significantly harder to prevent scripts from doing this.
The issue lies in 'how do you detect legit browser traffic from a script'. It turns out that this is not easy. You could try to detect 'unusual behavior' as much as possible (for example a large amount of requests in a short time), but this doesn't stop clients that are slower.
Ultimately if people want your data, they will find some way around whatever restrictions you come up with. You should reevaluate this and use one of the following options:
Don't do an SPA and API. Although one could wonder, if the data exists in HTML it can still be crawled.
Add authentication. But obviously this won't help you in any way if anyone can authenticate.
Re-evaluate why you have this restriction. What are you worried about? If you're worried about people taking your data and using it elsewhere, how does only showing it in a browser from 1 domain help with that? If you're worried about copyright theft, why not use a legal approach to this?
I've seen a lot of these types of questions, but in my opinion I haven't yet seen one that has a legitimate good reason to want this. But, maybe you're the first.
I believe I answered my question myself on a comment 30 minutes ago... I think with captcha I'm able to secure the REST API against unwanted access to my REST API
I am working on a bilingual application targeting Google Home, and the program needs to be able to correctly enunciate responses in a language other than English, even when the user request is in English.
I cannot find an API flag to set the TTS language for individual responses. Is there any mechanism for this?
Not yet, although there are hints about how it might be done in the future. (To be clear - there is no guarantee they will support it this way, or support such a feature at all.)
SSML supports the <voice> tag, which includes a languages attribute. Although Google's SSML documentation does not mention it, the <voice> tag is available, and some attributes (but not the languages attribute) do work. Given this hidden feature, it seems possible that multi-lingual support may be handled this way in the future.
In the meantime, you may wish to use the SSML <audio> tag to play a pre-recorded or otherwise generated clip.
Note that this doesn't address input in a different language than the locale the user has set.
I have a web site project, a mixture of complex dynamic pages and authored CMS-managed content. I have the tools for the complex dynamic part and would like a CMS that allows me to call it to retrieve content that's been approved, i.e. for web site inclusion.
To be clear, I need the complex dynamic part to be the master and the CMS-managed content to be served up as and when I want it.
I had thought they'd be loads of options around this - it being an obvious (to me) thing to want to do. I'd also thought that CMS's would naturally publish API's (web service based ideally) to enable this...but my research so far doesn't seem to show this. Hopefully I'm just missing a trick. Can anyone help?
I've looked, btw, at openText, Alfresco, Jahia, Enfold, Percussion, Interwoven, EPIServer, Ektron to name a few.
Ideally, I'd like an open source CMS solution if there is one, definitely can't afford the big $ that some of the vendors are looking for.
Am I right in assuming you are wanting to use an API or Service to retrieve content from the CMS that has been through some approval process?
This is definately possible with EPiServer, through either the code API or, if more appropriate, a webservice, although I think the price might be an issue here.
I've searched the web for this bit to no avail - I Hope some one can point me in the right direction. I'm happy to look things up, but its knowing where to start.
I am creating an iPhone app which takes content updates from a webserver and will also push feedback there. Whilst the content is obviously available via the app, I don't want the source address to be discovered and published my some unhelpful person so that it all becomes freely available.
I'm therefore looking at placing it in a mySQL database and possibly writing some PHP routines to provide access to my http(s) requests. That's all pretty new to me but I can probably do it. However, I'm not sure where to start with the security question. Something simple and straightforward would be great. Also, any guidance on whether to stick with the XML parser I currently have or to switch to JSON would be much appreciated.
The content consists of straightforward data but also html and images.
Doing exactly what you want (prevent users from 'unauthorized' apps to get access to this data') is rather difficult because at the end of the day, any access codes and/or URLs will be stored in your app for someone to dig up and exploit.
If you can, consider authenticating against the USER not the App. So that even if there is a 3rd party app created that can access this data from where ever you store it, you can still disable it on a per-user basis.
Like everything in the field of Information Security, you have to consider the cost-benefit. You need to weigh-up the value of your data vs. the cost of your security both in terms of actual development cost and the cost of protecting it as well as the cost of inconveniencing users to the point that you can't sell your data at all.
Good luck!
In GWT javadoc, we are advised
If you only need a simple label (text,
but not HTML), then the Label widget
is more appropriate, as it disallows
the use of HTML, which can lead to
potential security issues if not used
properly.
I would like to be educated/reminded about the security susceptibilities. It would be nice to list the description of the mechanisms of those risks.
Are the susceptibilities equally potent on GAE vs Amazon vs my home linux server?
Are they equally potent across the browser brands?
Thank you.
The security risk of using the HTML widget is that it doesn't escape html characters like the Label widget does. This opens up the possibility of Cross-site scripting (XSS). Therefore you should not use it to display data supplied from users. There's risk in itself to use it for string literals in your code.
How your GWT project is deployed doesn't matter much for the security risk, as the risk is there anyway if you allow user supplied data being printed back unescaped. But how your site is used, e.g. how much content is user contributed, and how popular your page is have a huge effect of how likely it is that someone actually will exploit a weakness.
Though ... if you have a habit of typing malicious javascript in your own sourcecode using Labels won't help anyway... :P