Sean Coates

Chris posted about Secure Logins, last week. In it, he describes the confusion that exists when users cross from HTTP to HTTPS via forms.

Chris isn't alone in noticing this problem. A few weeks ago, on the Security Now! podcast, Steve Gibson answered a user question about the same problem.

On Chris' blog, I mentioned that this would be a good use for Greasemonkey. (If you don't know about Greasemonkey, you should definitely check it out.)

Since then, I've had two flights, and took a little time to work out a solution to the problem.

When hovering a form button, image or submit input, you'll see a description of the form's action, and various potential problems (onsubmit, onclick, etc).

It doesn't solve all "hijacking" problems, but it's not supposed to.. it's just a quick indicator of where your form probably posts.

Even if you're not interested, take a look at the source for a cool little embedded image trick.

Enjoy.

If you don't read the PHP Internals mailing list, you've probably missed most of the recent discussion on namespaces.

Since you're reading this entry, there's a good chance you've read one of the other posts about the results of the 2005 PDM, though.

Of particular interest (especially given the recent Date class debacle) is the point on namespaces.

At the meeting, the core developers decided that "\" is a logical choice for the namespace operator as it is the only single non-alpha-numeric character on (US) keyboards that isn't yet an operator.

This has been met with some resistance.

For some reason, people don't seem to think that "\" is a good choice for the namespace operator. I'm not sure why this is... \ seems logical to me.

---

UPDATE: As you see, the title was changed from Shaloshayim Nekudotayim to Shalosh Nekudotayim. Check the comments--thanks Hebrew speakers.

---

Jessie Hernandez (the author of one of the existing namespace patches) originally proposed the use of ":" (as in "namespace:class::var").

This was rejected by the core developers because : is already an operator: it is used in the [url=http://php.net/ternary]ternary operator[/url]. It would make things like the following break:

[php]$foo = $bar?moo:oink:meow;[/php]

So, if $bar is true, does $foo become moo:oink? or oink:meow? So, no good.

One solution is to enforce whitespace around the ternary colon:

[php]$foo = $bar?moo:oink : meow;[/php]

I hope this never makes it into PHP. Fortunately, Rasmus has already denied it.

So, there have been a number of other ideas. Most of them are simply impossible ("." ? Seriously... it's the concatenation operator!).

I have absolutely no problem with "\". Some people have argued that "\" looks too much like "/". This is simply bogus. The same people think that ":" vs ";" is OK, but it's essentially the same comparison.

Barring \ (for whatever reason), I would like to see ":::". Yes, it's a little longer than the other operators, but who really cares? It's ONE extra keypress (you've already got shift held down from the previous colon.) Even Ilia agrees.

Why ::: ? Well, it makes sense. :: resolves scope, ::: should resolve the scope's scope. Right?

So, what's with the title of this entry, you ask? I had to do a little research to come up with it, and it might be completely wrong as I don't speak/write Hebrew, but, since :: is called "Paamayim Nekudotayim" (or "double colon" in English), I propose "Shaloshayim Nekudotayim" which (hopefully) means "triple colon." Feel free to correct me (-:

It's been a long time since I blogged. You might remember that I was looking for the perfect laptop. The search was due to imminent changes in my work-life (imminent at the time, but have been in place since the middle of September).

If you've read past entries in my blog, or recent issues of php|architect, you might remember that I became the Editor-in-Chief in the spring.

Around 6 weeks ago, I quit my job and started spending my days with Marco and the rest of the team at MTA (publisher of php|a).

It's been really great, so far, I've got my hands in a lot of projects, and I've been given some pretty serious responsibilities. Good times. (-:

I've finally found a few minutes to upgrade my s9y install, so I no longer have an excuse to avoid posting here.

I'm currently at php|works (like Marco, Wez, Derick, Ilia, Marcus, Rasmus, George, Chris, Lukas, Davey, and many others whom I'm probably forgetting).

It's been wonderful, so far. Interesting talks, great company, and an excellent venue.

As always, the best part is sharing mind-time with the guys I normally only see on IRC and in mails. Marco has been exceptionally hospitable.

In the same vein (mind-time sharing), I managed to get some work done on Livedocs, yesterday, and I bugged Ilia enough to commit my patches. In short: the search bar is now in the default theme, and the leftbar TOC now has the "current" breakout on the top of the list (suggested by both Wez and Lukas).

Up until today, I was really pumped up about the imminent release of PHP 5.1. Then I read this.

I'm still excited about 5.1, but it now pales in comparison to the potential that exists in 6.0.

The best part, though, is the general concensus of change that's attached to the thread.

Read on for my opinion on the points that have been brought up. Let's take a look at Rasmus' original ideas:

1. Remove register_globals completely Yes! Anyone with half a clue agrees that register_globals shouldn't be used. Let's help those with a lower clue-ration.

2. Remove magic_quotes_* Yes! Same rule as #1. I really hate cluttering up my (must-be-portable) code with stuff like "$var = get_magic_quotes_gpc() ? stripslashes($_GET['var']) : $_GET['var'];"

3. Add input filter extension which will include a mechanism for application developers to very easily turn it off which would swap the raw GPC arrays back in case the site had it turned on by default. I was originally against this idea. Well, more like against automatic filtering. I've since changed mind.

One of the things that I had the opportunity to chat with Rasmus about at Conf. PHP Quebec 2005 was admin-implied input filtering. He told me that input filtering should be an option of the system administrator, and shouldn't always be left in the developer's hands. This makes sense. It's primarily the developer's burden to write good code, but most of us run apps that weren't written by us. There should be some way to apply blanket filtering.

Obviously, to make this system work, there needs to be some way for the developer to access the raw, unfiltered content (yes, there ARE occasions where it's necessary to grab '<', '="">', and '"' from the request. My retort to Rasmus' theory of admin power was "If the developer can get to the raw data (and he has to be able to do this), how are we any better off? Yes, a good developer will use this mechanism ONLY when necessary, but what about a Jr. developer who 'learns' from the wrong piece of code?" His answer: it'll be simple to grep for this mechanism. So, I conceded. I'm now all-for an automatic input filter.

4. Include an opcode cache by default. A lot of work has gone into pecl/apc recently, but I am not hung up on which one goes in.

Zend politics aside, I don't know why this hasn't been pushed harder before. +1

5. Remove safe_mode and focus on open_basedir I've never had the.. uh.. "pleasure" of working with safe_mode, professionally, but this SEEMS like the best option. Yes, it will upset a LOT of web hosts. Hopefully they'll see the light. I'm not holding my breath, though.

6. Remove some stuff that has been marked deprecated since PHP 3/4 Please, yes. With the exception of dl() (-:

7. Make identifiers case-sensitive

8. Remove various function aliases

These, I don't really care about. Either way is fine by me.

So there's my 2¢ (Canadian).

What do you think?