Category: General

General bullstuff

Disable autocomplete / autofill in Chrome 51 for typeahead

So all the old insane tricks don't seem to work anymore, right? Well, I've seen one where you create a bunch of retarded hidden fields, but that's inelegant and adds too much complexity. So, based on something I found rarely mentioned, I manged to assemble this:

The type "search" makes it to where Chrome will not apply autocoplete or autofill, however some browsers like Firefox still will, so you also add the classic autocomplete="off".

It works with typeahead and Bootstrap 3 just fine, however if you have specific styles for input[type='text'] you'll have to include 'search' as well.

It's also a valid HTML5 element as well, and in HTML4 or (X)HTML 1.x most browsers will fail to text even though it says search, so it may not be valid, but it will work, and that's more important.

So, good luck, until Chrome changes this too and wants to punish developers. As they claim, turning off autocomplete isn't really a security feature, that's nonsense because I'm not using it for security.

They say that we should take advantage of autocomplete and autofill, but that logic doesn't seem to include the fact that maybe people other than Google have search suggestions, or even hidden values like numerical IDs which need to be applied when the item is selected — something autofill doesn't do and Google doesn't seem to give a damn.

Google Chrome actually stealing mundane ideas from Opera?

Note from the future: this was originally written before Opera became Chrome Jr.

A week or so ago, not sure when, Opera updated; nothing was really different, except the autosuggest / autofill items were now bold. I didn't think much of it, until Chrome updated, suddenly theirs were bold too.

What the…?

So, I went out looking for answers. One of the first things I noticed was since about May 4th, a lot of people were talking about Chrome's bold autofill lists; primarily asking how they could restyle that. I didn't find anyone talking about how Opera had done the same thing.

Granted, Opera is not really the most popular browser, and I use it for testing purposes primarily, but nevertheless this change really stands out to me. Not necessarily because one browser copied another, but because the copy is so mundane and silly. Is there some massive benefit to bold auto-fill or bold auto-suggest items?

Is it so revolutionary that when Opera updated, some Google Chrome hacker said "HOLY TOLEDO, WE GOTTA DO THAT, RIGHT NOW, PUSH IT OUT ASAP! WE CAN'T BE LEFT BEHIND! THIS IS DISRUPTIVE!"?

I've tried to find out if there's any discussion from either company regarding this, but I sure can't find it. If anyone has any information, I'd sure like to know why this was done, because it's so goofy.

Exchange and PHP, a nightmare with a solution

OK that title is not very smooth or clever, but a project I worked on several years ago was syncing Microsoft Exchange with PHP. There's a lot out there not documented, primarily because there are several problems with PHP's implementation of XML and Microsoft's over-use of namespaces and so forth. However, with some serious hacking, I've come up with some solutions.

This was initially based on some code I had found online, however it was so long ago I have not been able to figure it out so I cannot provide proper attribution. Additionally, impersonation does work, and I've seen a lot of people have a problem with this as well.

The biggest thing is it requires a lot of manual XML to actually work, you can't build the objects and expect it to work correctly, it literally will not, primarily due to PHP's SOAP class.

The primary benefit of this code is to see how I hacked around dealing with PHP's issues when it came to trying to deal with the Exchange calendar and task system.

Feel free to reply with any fixes, updates, etc.

A few things to note:

  • When I created this, it was a hackfest with very little time, so the code is not my best work at all; I mean it uses globals for god sake, and improper OOP, improper usage of PSR, classes doing far too much, etc.
  • This code was built for PHP 5.2 – 5.4, and takes no advantage of PHP 7 or anything.
  • Yes, those two above mean I am embarrassed by the quality of this code, but hiding it isn't really useful to anyone, especially because I am not using it in my project any more.
  • This will not work out of box, because it was built specifically for my project, however because it was such a nightmare and other people are struggling, I'm sharing it. It should give you a good idea of where to start and how to deal with some hiccoughs.
  • I assume you've already got the basis down, and you've got messages.xsd, Services.wsdl, and types.xsd, and all the other stuff. Basically I am just assuming you've got it working, you're just running into problems actually doing anything useful.

Usage from my job which pull down basically everything first. This is because repeating calendar entries are only listed once, so you have to pre-grab and store everything in order to deal with it later. The most important aspects are storing the ID and change key so that you can properly manage it later. If someone edits a calendar entry, the change key will be "changed," so every once in a while, depending on your desire of accuracy, you may need to resync everything, unless you find a better way to do it (if so please share).

Here's the classes:

Is PHP out of fashion?

One thing I keep running into is the claim that "PHP is out of fashion," which I don't quite understand considering PHP is the most popular server-side language on the entire Internet, and many of the top websites in the world use it. Indeed, even on Twitter recently I had this conversation (edited for readability, see link for context):

Faizan Javed (‏@faizanj): A bigger issue – what is it with valley startups and PHP?
Tony Showoff ‏(@TonyShowoff): What do you mean? The polarisation of it, to where either it's evil or it's the only thing used?
Faizan Javed (‏@faizanj): the intense focus and controversy over an arguably out-of-fashion language.
Tony Showoff ‏(@TonyShowoff): Java is also "out of fashion" but still used, PHP is used by more web sites than any other language. I think it's inadequacy. A lot of things go in and out of fashion, but fashion doesn't reflect usefulness. Remember the coming p2p/push/xml/etc revolutions?
Faizan Javed (‏@faizanj): one can argue Cobol and Fortran are also still useful in their domains. But hip, cool and mainstream they are not.
Tony Showoff ‏(@TonyShowoff): So is hand looming one could say, but half of all internet sites don't use COBOL and half of looms aren't hand driven.

Like underwear, PHP is becoming cleaner, as if it's been washed with Tempa-Cheer on double rinse at high heat.

I think he does bring up a good point and question though. Are COBOL and Fortran fashionable at all since they still are in use, mostly in the realm of maintenance? Well, maybe, but I don't think so. As I tried to point out as best I could on Twitter, niche use cases are not the same thing as something being ubiquitous. Just as you can still find handloomers that doesn't mean machine looming is falling out of fashion, despite the rise in custom hand made items on etsy.com

I think people often confuse what's cool with what's in fashion and what's useful or available. This is less of a big deal in pop culture trends, but in the computer world it doesn't really make much sense. Sure, PHP may not be cool, I'm not sure if it ever was, but that doesn't change the fact that to this day when you want to find a web host, almost always they have PHP hosting available and not much, if anything else. Despite Python and Ruby becoming more hip, along with Erlang and the less useful other things which are some goofy spin off of another thing, they simply aren't available everywhere or ubiquitous.

So, in a sense, asking whether or not PHP is in fashion is sort of like asking whether or not underwear is in fashion. Sure it may be cool, or sexy, not to wear it, but for the most part you'll find it everywhere you look. Is that a bad analogy for PHP? Maybe, but reflecting PHP's problems over the years, I think it's pretty apt, but like underwear, PHP is becoming cleaner, as if it's been washed with Tempa-Cheer on double rinse at high heat.

But what about the numbers (click image for source information)?

stats-w3techs

php-trend-201301-netcraft

And finally, what about as far as community help goes? After all, a programming language's success and usability these days often relies on thriving communities. Well…

tiobe-community-stats

Uncool? Maybe, but no programming language has ever been cool. Out of fashion? I don't think so.

Should you trim passwords?

A question I see asked from time to time is whether or not web sites should trim passwords on account creation and login. More often than not the typical responses show both a complete lack of understanding of what "trim" even means from people who should know better, and a lack of understanding that not every user is Dade Murphy after he just got in from grindin' some serious hand rails. Though not everyone has their head up their ass or argues from a position of complete ignorance.

So consider:

  • Trim means to remove white space from the beginning and end of a string, not the center.
  • Even if you don't email passwords or display them anywhere, users will still copy/paste them to each other and various places and often this will add a space or \n to the end of the string.

A few things are clear to me based on my experience and reading what others had to say about it:

  1. People who are against trimming passwords either don't know what trim means, or think everyone else understands and uses simple security protocols like not saving passwords in word processors
  2. People who are against trimming passwords probably have never had to deal with real users or customers, and probably are some shitty wanna be Richard Stallman with more than slightly high expectations of what users can and should be able to do
  3. Users should be allowed to have spaces within the string itself, but not on either end, in order to save your support people (and possibly yourself) a lot of headaches
  4. People who are against it assume that if there's a space it's because a user intended it, but how many people actually put spaces at the end of passwords? Basically fucking nobody.

So it's simple: users should be able to use any characters they want in a password, but the password should be trimmed at both create and login. There's also no reason to warn people that passwords are trimmed, again because nobody understands what the fuck this means, even apparently technical people. We know from massive lists of cracked and leaked plain text passwords that nobody uses spaces at the end of passwords, not even keyboard cowboys who give bad advice on Stack Overflow.

Trim away my friends, don't listen to people who probably don't even have clients.