Bored? Take a look here at all you’ll ever need to know about CSS positioning (well, until the article on floats comes out).
Category: Web development
Limiting the number of characters entered into a textarea or input box
I bet that title just grabbed you, yes? Well, sound boring it may do, but it’s been a bit of a problem for web designers for a long while now. However I’ve just made things a little easier with the latest addition to my Performer library. Suffice to say the new function is called ‘Limiter’ and does what it says on the tin.
I’d also like to thank kourge for very helpful suggestions and input on the source code that’s made Performer a lot more streamlined.
Website security
A few recent goings-on (going-ons?) have made me think about website security. Firstly was the flurry of interest about Open ID, which is an open, distributed identity system. Basically you set up one Open ID account and use that account to log into websites, applications and services which support it.
It’s not without it’s problems, but in general it seems like a good idea. You just have to remember your open ID address (which, for me, could be the address of my website and then you’re prompted for your Open ID password. Easy, and it’s the same for every Open ID-enabled site you visit.
Secondly we’ve had a whole series of – frankly quite animated – discussions at work about persistent logins for web applications. You know the type of thing: you log in, ticking the “Remember me” button, and next time you visit (a few days later, perhaps) you’re logged in automatically.
Great, but that does intoduce some problems. Mainly that as long as you’re on your computer, under your operating system login, it works great. When you go to someone elses computer, or use another login, or (even worse) you don’t have any logins on your operating system and your computer gets stolen, lost or hacked – anyone can pretend to be you in the web application.
It’s a well-known problem, and most developers get around it by putting a sensible expiry time on the automatic login cookie, something like a week or a month works fine. But some want customers to never have to log in after they’ve done so for the first time. Ouch.
You see, if we think that customer won’t be able to remember a password – even when we provide a “Forgotten your password?” link on the login screen – can we trust them to not load one of these indefinate login cookies on a non-secure system? I don’t think so, and once the cookie is there anyone just going to the right address has access to the data.
We’ll find a solution to this problem soon. We’re good at doing stuff like that; it’s what we do.
In the meantime, I had a thought. How about a browser plugin that handles security? My browser of choice has an entire universe of plugins that do all manner of clever things.
My thinking is like this. The user logs onto their operaing system (say, Windows) and opens a browser with the security plugin installed. Because the browser, and therefore the plugin, is part of the operating system it can get the currently logged in username and send that (via SSL) to the web application, which verifies it against a list of users. Perhaps a token/key could be used to make it even more secure. The web application then logs the user in as themselves.
That way, you log onto one system and the web application uses that login to verify who you say you are. Some websites with integrated Windows authentication use this already, admittedly without a browser plugin, but this way would be cross-platform (both client and server).
As long as you had the plugin (which could be verified regularly) and your operating system login was secure, you’d be laughing. Or chuckling a bit, at least.
Do you see any problems with that idea? Tell me, there’s normally something major I miss.
Playing the sharing
One of my favourite free music site is 3hive, although these days I rarely get a chance to download much stuff. The problem is I have to download something before I know whether it floats my boat, so to speak. Even with broadband that’s a few seconds per song, which soon adds up.
Not any more. If you’re a user of the greasy monkey for Firefox, you’re in luck. Just download this GreaseMonkey script and you’ll get a little Flash player below each download link. You can preview each track before you download with a mere click of the mouse. The Flash player was written by Jeroen Wijering and he’s kindly giving it away free. In this version of the 3hive player the Flash file is run from my website, but you can easily amend the script to run the file from somewhere else.
Happy listening!
Extending Performer
Only a day or two old and already my JavaScript library baby is learning new stuff. Namely it’s learnt how to pass the selected value of a select element to a remote page and load the response of that page into a named element. If you didn’t understand that, don’t worry. I’m barely there myself. So let me give an example.
Let’s say you have a list of musical styles and when someone chooses one you want to send their selection to a remote page. That remote page will look at their selection and bring back a load of sub-genres for that genre. So if they choose ‘Rock’ they will get back ‘Indie’, ‘metal’, ‘Glam’ etc. With me so far?
That remote page could build a new list of all the sub-genres, and Performer will take that sub-genre list and load it back into the original page inside the element you specify. And all that in the blink of an eye, or at least click of a mouse. Or, indeed, the press of a key – this function (and all the others, as far as my testing has proved) is keyboard-friendly.
Anyway, give it a whirl.