This started as an email to my friends and family that are iPhone owners, but I figured I might as well post it here too.
I'm not sure how true or severe this is, but I figure it's better to have information in advance so you know what to expect. It seems to be a legitimate article from a reputable source... so I'm fairly convinced it's true.
How To Hijack 'Every iPhone in the World'
My Summary: There's a bug in the iPhone SMS software that allows someone to send you a series of SMS messages, only one of which will show up. The guy in the article says the visible message from his version will only have 1 character, a square, but his method could be easily changed by another hacker to display another message, perhaps to look more innocuous. It looks like it will work in the same fashion as an internet worm: Spreading by sending itself to your contacts -- so you will probably get the message from someone you know.
The only way to stop it from spreading is to immediately turn your phone off after receiving the message. It's not clear if or when you'll be able to turn it back on.
I would assume, but am not sure, that if you immediately turned it off, and then only turned it back on when you were ready to immediately restore from your most recent backup (which is made when you connect to iTunes), that might remove the malicious code... but then it's just a matter of time until you get it again. The more people that know you, the better your chances for getting infected (and again, and again, and again...).
Scary stuff! I hope Apple addresses this quickly.
Update: A friend informed me that hitting the Check for Update button in iTunes netted him the 3.0.1 firmware. Indeed, it's now available and the only note in the change log was that the SMS bug had beed addressed. I can finally stop worrying.
Published 2009-07-30 @ 12:11 in
I'm happy to announce that my Related Entries plugin for Mango Blog has finally gotten the attention it so desperately needed. I've been swamped at work (in a good way -- up to my eyeballs in learning Flex and writing applications for classroom use), and just haven't had the energy or brain power to work on these projects when I get home. I owe a debt of gratitude to my wife, who graciously allows me an evening every now and then away from some family and household obligations to work on projects like this; and to Mark Aplet, who is always willing to be my crash test dummy. In addition to today's update for Related Entries, I have some updates for Scribe in the pipeline as well.
The short version of the story is that I've fixed some significant bugs:
- Railo incompatibility due to core function name collision (part of JSONUtil, but I've adjusted for it. I've also filed a bug report and am working with Nathan to find the best solution for it.)
- Case-sensitive Operating System incompatibility -- I was mixing references to "jsonutil" with a file named "JSONUtil".
- Reverse-links (when you relate post A to post B, I automatically relate post B back to post A -- this is called a reverse link) were being improperly stored, and in most cases would be displayed on your blog, but you could not remove them in admin.
The case-sensitivity thing is a common gotcha, but I am a human and I work on Windows/OSX most of the time, where this isn't a problem. Please forgive the error. To make up for it, I'm offering Related Entries at half price all this week!
Fixing the reverse-links has proven to be a tricky task. I've tested this now on ColdFusion 8, ColdFusion 9, and Railo; and I am fairly confident that I've got a decent solution. You have two options.
- For users who use SQL Server as your database, and have fairly high permissions, I have an SQL script that should fix the data for you. The only caveat with the script is that it assumes your Mango install's tables do not use a table prefix. If they do, you'll need to edit the script accordingly. (Update references to both entry_custom_field and entry to [prefix]entry_custom_field and [prefix]entry, respectively.)
Of course, you should back up your database before running this script. I will apologize profusely if it messes something up, but that's about all you'll get from me.
- For MySQL users, or SQL Server users who don't have adequate permission to run a custom script, the plugin should be (somewhat) self-correcting. If you know you have an entry with some strange behavior around Related Entries: edit that entry, double-click each related entry in the 3rd listbox to remove it -- until the box is empty, and then add related entries back. This should fix most otherwise-unexplainable issues. Unfortunately, I don't think it will fix reverse-links that you can't remove. I hope to provide another release soon that will automatically fix these, but I wanted to get this part of the fix out there, so that at least no more bad data is created.
No matter which of the above two options you choose, you should update to prevent further bad data from being created.
And don't forget to grab the SQL script, if you have the ability to run it.
- Related Entries
- Mango Blog 1.3+
- Auto-install URL:
Published 2009-07-30 @ 07:30 in
I officially moved my blog to this domain today in 2008. Prior to its life on this domain, I was writing this blog as a sub-folder on the domain I use for my family blog, since April of 2007.
So happy 1st birthday, FusionGrokker.com! It's been a fun year. Here's to another.
Published 2009-07-23 @ 08:00 in
Recently it was announced that ColdFusion 9 will add a way to explicitly access the existing "var" scope inside functions, using a new scope named "local".
There has been some confusion, including on my own part, about exactly how it is implemented -- so I thought I would do what I can to clear it up.
For starters, and as is always a top priority with ColdFusion upgrades, old code shouldn't break because of this change. While it is true that the following two lines are analagous, they are both still supported for the forseeable future:
<cfset var foo="bar">
In addition, you will be able to create var/local-scoped variables anywhere in the method, not just at the top. Right off the bat, this is awesome and can cut down on quite a bit of typing. This:
<cfset var foo=""><!--- or: <cfset local.foo = "" /> --->
can become this, if you like:
How awesome is that? I'll tell you. Really awesome.
Now, on to some trickier things...
The "local" scope gives you explicit access to variables set in this scope. The scope has always been there; CF9 is just adding the local scope so that you can explicitly access it (read from it).
Previously, the only way to read variables from this scope was to imply that was where you wanted them from, by not including a scope name. ColdFusion would then infer that -- since the variable exists in the unnamed local scope -- that's what you wanted. To put it more explicitly, ColdFusion checks for the requested variable in several different scopes, and inside a method the unnamed local scope is at the top of that list. The first scope that contained a matching variable would be the value you got back. Now we'll have an explicit way to specify which scope to read from, including the previously-unnamed local scope.
Does this mean you don't have to var-scope any more?
But now you have two choices: Use the "var" keyword, or the local scope. As before, (and, I'm sure, partly to maintain backwards compatibility) if you neglect to include one of these indications that the variable is local, it will go into the object's global "variables" scope, which if not taken into proper consideration, is not thread-safe.
What happens to
<cfset var local=structNew()/> ?
Without the ability to explicitly reference the unnamed local scope, the convention of creating a var-scoped structure named "local" was adopted as a community standard over years since the popularization of CFCs. As a result, you'll see a lot of existing code that has a var-scoped "local" structure.
If no special exceptions were made, then what you might end up with would be your custom "local" structure inside the local scope, something like the following:
Seems logical, right? Well that's not what happens. For whatever reason, in their infinite wisdom (and who am I to argue?), Adobe decided the better thing to do was to detect this case, and
force the new structure into the object's global "variables" scope, so instead, this is what you end up with: Update: It just gets ignored, as Ben Forta's post states. (The confusion here was that at the time he wrote that, the beta didn't do what he said it would. It's since been fixed.)
... With one small exception, that I've found so far: If you execute a query and assign it to the local scope, like my 2nd code sample above (
<cfquery name="local.foo">), for some odd reason, a key named "cfquery.executiontime" is added to the object's global variables scope:
For the most part, you can probably ignore that. But, on the off chance that you need it, now you know where to find it. Oh, and notice that it's got a period as part of the key name, so you can't use "variables.cfquery.executiontime" (well, ok, it might work, I didn't try...), but you would be better off using the syntax:
foo = variables['cfquery.executiontime']; ... and it's not thread-safe. So that's probably a bug, and will probably get fixed before release.
Scope precedence is still exactly the same as it was previously:
- Function local (UDFs and CFCs only)
- Thread local (inside threads only)
- Variables (local scope)
Server, Application, Session, Request, and Attributes scopes (still) require that they are explicitly named in order to read a variable from them. (Did I miss any?)
Published 2009-07-09 @ 03:22 in