Like it or not, Apple plays a critical part in the app-based economy these
days. Part of this is having an Apple Developer account in order to release
apps to the App Store™️, and in order to get an Apple Developer account you
need an Apple ID. In order for the Apple ID to be able to become an Apple
Developer account, it needs to be considered to be “over 18”, even if it’s a
company account and a Date of Birth makes no sense whatsoever. This is where
I got stuck.
I use Mozilla Firefox as my browser and occasionally I’ve found that certain
error NS_ERROR_FILE_CORRUPTED, which is displayed in the console. For me,
this is rarely seen, though I’ve experienced the issue a few times on
Trello.com and another on our corporate website CMS. This has the effect of
preventing whatever that resource was from loading, so in the case of CSS it
won’t display and in the case of JS it won’t run. On Trello, this resulted in
a fully broken …
I’ve been doing a variety of things pertaining to web security in recent weeks
and one thing that’s been gnawing at my brain is the fact that my blog could
still only use insecure http:// because of GitHub Pages. My blog’s
content was using GitHub Pages for its serving and gh-pages really hasn’t
been seeing a lot of love - that I know of - since its inception a few years
back, especially since the development of concepts like Let’s Encrypt with
free SSL certs for the web.
All information here on a server level is related to RHEL 6. You will
need to change some instructions for Debian based systems. CentOS
should be fine and needs only a minor URL change in the repo configuration.
After a switching away from Apache some time ago, our primary web server
had been running Cherokee for quite a while
- since September 2011, in fact, looking back at the configuration history.
More recently, however, I’ve switched us again. This time to Nginx - with impressive improvements in performance and
configurability (10x for some static files) — and reliability.
Originally, the selection of Cherokee as web server software looked
promising - the Cherokee project had been around for a while, was gathering
support, had a reasonable level of uptake, and consistent …
Serving up uWSGI application using Nginx is super-simple and is configured
effectively like a standard reverse proxy_pass. However, the documentation
isn’t entirely clear exactly how one can correctly serve an application
against a sub-directory — and have the application know its correct path
such that it can create correct URLs.
Coming from a background of using the Cherokee webserver, uWSGI operated
slightly differently within its configuration. This behaviour, as best I
know, must have modified the given uWSGI parameters to correctly handle the
sub-directory path. I haven’t looked into it, but it probably just does
the same thing that …
uWSGI is extremely promising as an application server given its huge
range of options and supported platforms. For me, however, just getting
something seemingly simple up and running successfully was relatively
confusing. I’d like to contribute to the documentation when I can, but
thought a dedicated page about TileStache as a specific application
(and associated configuration) was warranted. It does make more sense
I want to serve my TileStache application at http://mydomain.com/tiles
(taking careful note of the sub-directory present). I’ve chosen an
INI-style configuration for my instance and here’s what the …
CAS (Central Authentication Service) is a single-sign-on service (say
that several times quickly) and through accessing a CAS/logoutURL,
as an application, you’re able to log the given user out. What wasn’t
clear (by Googling) was whether there’s a possibility to redirect the
user back to the original application (or a given URL). I now know,
thanks to the CAS Protocol Documentation (section 2.3), that any
posts that mention adding ?service=http://my.url/ to the /logoutURL are incorrect, as this isn’t a valid parameter (at least not at time
We all see web pages like Internet banking, HR systems, email, and more
that allow you to log in, do something and load pages, log out, and then
prevent you from using your browser’s history to see that sensitive
information. I’m amazed that in my searches I couldn’t quickly find a
definitive source of information on how to achieve this. Pages across
the web in a search for ‘stop caching’ range from blog posts, to forum
posts, to other pages, and people asking the question (try it: here,
or maybe here).
Apache does something interesting (yes, I still
think it’s logical) when you’re accessing a directory that it’s serving:
if you access it without a trailing slash, it’ll add one by default.
This makes sense if you’re going after some static content or a folder
index (or pretty much any sane usage) but it didn’t fit my use case of
serving Plone using rewrite rules in a .htaccess file.
The issue that arises for myself with Plone is that my sites need to
have their access customised through that .htaccess file and that’s been …