The roads I take...

KaiRo's weBlog

Dezember 2016
1234
567891011
12131415161718
19202122232425
262728293031

Zeige die letzten Beiträge mit "CBSM" gekennzeichnet an. Zurück zu allen aktuellen Beiträgen

Populäre Tags: Mozilla, SeaMonkey, L10n, Status, Firefox

Verwendete Sprachen: Deutsch, Englisch

Archiv:

Dezember 2016

November 2016

Oktober 2016

weitere...

3. Oktober 2016

The Neverending Question of Login Systems

I put a lot of work into my content management system in the last week(s), first because I had the time to work on some ongoing backend rework/improvements (after some design improvements on this blog site and my main site) but then to tackle an issue that has been lingering for a while: the handling of logins for users.

When I first created the system (about 13 years ago), I did put simple user and password input fields into place and yes, I didn't know better (just like many people designing small sites probably did and maybe still do) and made a few mistakes there like storing passwords without enough security precautions or sending them in plaintext to people via email (I know, causes a WTF moment in even myself nowadays but back then I didn't know better).

And I was very happy when the seemingly right solution for this came along: Have really trustworthy people who know how to deal with it store the passwords and delegate the login process to them - ideally in a decentralized way. In other words, I cheered for Mozilla Persona (or the BrowserID protocol) and integrated my code with that system (about 5 years ago), switching most of my small sites in this content management system over to it fully.

Yay, no need to make my system store and handles passwords in a really safe and secure way as it didn't need to store passwords any more at all! Everything is awesome, let's tackle other issues. Or so I thought. But, if you haven't heard of that, Persona is being shut down on November 30, 2016. Bummer.

So what were the alternatives for my small websites?

Well, I could go back to handling passwords myself, with a lot of research into actually secure practices and a lot of coding to get things right, and probably quite a bit of bugfixing afterwards, and ongoing maintenance to keep up with ever-growing security challenges. Not really something I was wanting to go with, also because it may make my server's database more attractive to break into (though there aren't many different people with actual logins).

Another alternative is using delegated login via Facebook, Google, GitHub or others (the big question is who), using the OAuth2 protocol. Now there's two issues there: First, OAuth2 isn't really made for delegated login but for authentication of using some resource (via an API), so it doesn't return a login identifier (e.g. email address) but rather an access token for resources and needs another potentially failure-prone roundtrip to actually get such an identifier - so it's more complicated than e.g. Persona (because using it just for login is basically misusing it). Second, the OAuth2 providers I know of are entities to whom I don't want to tell every login on my content management system, both because their Terms of Service allow them to sell that information to anyone, and second because I don't trust them enough to know about each and every one of those logins.

Firefox Accounts would be an interesting option, given that Mozilla is trustworthy on the side of dealing with password data and wouldn't sell login data or things like that, may support the same BrowserID assertion/verification flow as Persona (which I have implemented already), but it doesn't (yet) support non-Mozilla sites to use it (and given that it's a CMS, I'd have multiple non-Mozilla sites I'd need to use it for). It also seems to support an OAuth2 flow, so may be an option with that as well if it would be open to use at this point - and I need something before Persona goes away, obviously.

Other options, like "passwordless" logins that usually require a roundtrip to your email account or mobile phone on every login sounded too inconvenient for me to use.

That said, I didn't find anything "better" as a Persona replacement than OAuth2, so I took an online course on it, then put a lot of time into implementing it and I have a prototype working with GitHub's implementation (while I don't feel to trust them with all those logins, I felt they are OK enough to use for testing against). That took quite some work as well, but some of the abstraction I did for Persona implementation can be almost or completely reused (in the latter case, I just abstracted things to a level that works for both) - and there's potential in for example getting some more info than an email from the OAuth2 provider and prefill some profile fields on user creation. That said, I'm still wondering about an OAuth2 provider that's trustworthy enough privacy-wise - ideally it would just be a login service, so I don't have to go and require people to register for a whole different web service to use my content management system. Even with the fallback alone and without the federation to IdPs, Mozilla Persona was nicely in that category, and Firefox Accounts would be as well if they were open to use publicly. (Even better would be if the browser itself would act as an identity/login agent and I could just get a verified email from it as some ideas behind BrowserID and Firefox Accounts implied as a vision.)

I was also wondering about potentially hosting my own OAuth2 provider, but then I'd need to devise secure password handling on my server yet again and I originally wanted to avoid that. And I'd need to write all that code - unless I find out how to easily run existing code for an OAuth2 or BrowserID provider on my server.

So, I'm not really happy yet but I have something that can go into production fast if I don't find a better variant before Persona shuts down for good. Do you, dear reader, face similar issues and/or know of good solutions that can help?

Von KaiRo, um 21:21 | Tags: BrowserID, CBSM, identity, login, Mozilla, OAuth2, Persona | 2 Kommentare | TrackBack: 0

5. Mai 2007

Do I wanna git more?

I've been hearing about git for a long time as I already was following LWN.net closely when all those BitKeeper vs. Linux kernel problems came up and Linus started to work on a replacement. Meanwhile, over just two years, that technology has matured enough that it's being used by a wide rage of projects nowadays.

While the Mozilla project will use Mercurial ("hg") in the future, I suggested trying git a few times and probably annoyed decision makers a bit with that, but our big problem is that we need decent support on Windows, and git is not there yet (even though current development looks promising for the future). Mercurial is probably a good choice as well, interestingly it has been started about at the same time as git for practically the same reasons - and it's probably compatible in multiple ways: Not only are both distributed version control systems (DVCSes), they're both using SHA-1 hashes to identify revisions, and even screen shots of their graphical tools look similar.

In any case, I've personally never used anything else than CVS, and that aged, centralized, per-file version control system has served me well for my private projects. I understand its usage as well as its repository quite well and I hardly ever run into its real problems like file moving or such.

That said, I always found git's concept of tracking content instead of files interesting (that's why file moves are more or less irrelevant to it), and tracking changesets instead of single-file-changes could also prove useful in my personal projects. Oh, and then there's one thing that really attracts me about DCVS solutions: I'm doing lots of work when I'm on a train without a net connection, history can prove useful to have there, as well as tracking several different changes to a single file - and then I'm merging this to my other computer and two production systems (or actually, checking in to a central repository and check out on those systems, in the CVS model). And then, learning new technologies is always a good thing.

So, I had enough reasons to try out git for my personal projects, and I spent about 6 hours today figuring out how to work with it, a set of directories I wanted to import, and how to import those from CVS. So far, it looks like everything has worked. Oh, and the PHP code generating this website and blog (the CBSM system) is now running off a git checkout. :)

After some time of working with this, I'll see if I want to git even more code into such repositories - for now, let's see how this works out ;-)

Von KaiRo, um 02:03 | Tags: CBSM, git, hg, Mozilla | 3 Kommentare | TrackBack: 0

12. April 2007

UME-Blogs gestartet

Das heir verwendete Weblog-System wurde ja nicht nur für mein persönliches Blog hier verwendet, sondern, um im CBSM-System sowie im damit verwandten Community-System (fynf.at und andere) überall verwendbar zu sein.
Dabei können nicht nur "offizielle" Blogs diverser Websites eingerichtet werden, sondern auch persönliche Blogs der registrierten Benutzer auf diesen Websites bzw. Communities.

Auf der Homepage der UME ("Unsere Macht Europa", eine virtuelle Partei im Online-Spiel "Power of Politics) ist jetzt der Anfang mit diesen persönlichen Blogs gemacht, auf http://ume.waehlt.at/blogs/ gibt's eine Übersicht der aktuellesten Beiträge in den dortigen Blogs.
Ich hoffe, dieses Feature wird noch kräftig genutzt und die Community der UME wird dadurch gut gefördert!

Von KaiRo, um 17:19 | Tags: blog, CBSM, PoP | keine Kommentare | TrackBack: 0

26. März 2007

Pingback and TrackBack: ease of implementation (or not)

Finally I managed to implement pingback in addition to TrackBack, and it was interesting to implement both, to compare them from a developer's perspective - as both are technologies that enable other blogs to link back blog entries that link them and this way create a permanent connection between two blogs.

One target of pingback is said to be that it should be "implementable with minimal effort", I also read in a few places that it should not attract spam as easily as TrackBack. The latter has been achieved quite nicely, as the pingback client needs to tell the server the source URL containing the original link as well as its target, and the server needs to verify this link to this target actually exists in the source. TrackBack on the other hand just sends the the URL to link back to and needs no verifications, so strictly according to the spec, a TrackBack server just links back to anything anyone else tells it to link. Of course, most TrackBack servers nowadays do verify that their blog is linked from the source - as does this blog here, like I pointed out in a recent post here.
The ease of implementation was not such a clear win for pingback though in my case. Where it clearly wins over TrackBack is "autodiscovery" (automatically discovering link targets in a blog entry that are able to link back via one of those technologies): While TrackBack uses a rather complicated to detect RDF snippet that needs to be placed in the entry, pingback uses a very easy to read HTTP header (and an also easy to detect HTML <link> tag as a fallback) to detect if some page is pingback-enabled. Telling the other blog that it should link, i.e. actually "pinging" it, is quite simple on the TrackBack side though: do a simple HTTP POST with urlencoded data, get very simple XML as a reply that tells if it was successful or not, and that's it. Pingback on the other hand achieves that part via an XML-RPC call. This might be easy to implement if you have an XML-RPC server running on your site already, but if you don't, it requires you to send a rather deeply structured XML document in a POST request as a client, and as a server, to retrieve the data from that doc (I needed to spend some time to even find out how to get this body of the incoming request in PHP) and send an even more complicated XML reply. So the implementation of the actual ping is (without having working XML-RPC support in place already) much harder for pingback than for TrackBack. I guess there's rarely a technology that has only good sides to it...

BTW, I know that there's some XML-RPC support bundled with PHP (via XMLRPC-EPI), but as there's no good documentation of it anywhere (one case where the else good PHP manual really sucks), I even felt safer to manually deal with that form of communication.

That said, I got both technologies to hopefully work now on this blogging system, including autodiscovery for both of them (if both are supported, pingback is preferred), and I hope users of CBSM and our community system will like them. :)

Von KaiRo, um 01:29 | Tags: blog, CBSM | keine Kommentare | TrackBack: 2

9. März 2007

feeds available for this blog

OK, after some more work, this blog is available through RSS and Atom feeds (Firefox and IE7 users should see the feed icon popping up, SeaMonkey users with the link toolbar enabled should see them listed there under "More > Other Versions" (from the blog overview page).

Once I have the tagging system in place, there will be filtered feeds available that list only certain tags and/or languages. For now, the feeds just list the articles the blog overview page carries - the RSS feed has subjects and links, the atom feed includes the full articles as well.

I probably should try to get the blog syndicated on some planet sites now :)

Von KaiRo, um 02:13 | Tags: blog, CBSM | 1 Kommentar | TrackBack: 0

Feeds: RSS/Atom