View portfolio

Navigation



About This Site

This is the personal blog of John F. Morton. It's where I talk about the stuff that interests me. Primarily technology, marketing and pop culture. If you are looking to see what I do when I'm not blogging, visit jmx2.com for a taste. Thanks for stopping by!


Shameless Facebook Plug

Search


Advanced Search


Twitter Updates Twitter bird, very tiny.

    Follow me on Twitter


    Monthly Archives

    Syndicate

    Alltop, all the cool kids (and me)
    Sunday, February 07, 2010

    Quick tip: Expression Engine Microformatted date

    Another day, another EE tidbit. I wanted to export the entries from my blog in a simple text backup (MT Export Format). In the Expression Engine support wiki, there is an entry on how to do this in the 1.6.8 version, but I’m using 2.0.1 public beta. I had to do a few modifications to make it work in the new version. I posted my code on the Wiki, but if you ended up here looking for export tips, here’s how I did it.

    First, as the wiki page says, make a new template group called ‘export’. The ‘index’ file in that new template group should contain the following code. Be sure to update the “default site” to whatever your channel is called.

    {exp:channel:entries channel="default_site" limit="999" rdf="off"} 
    AUTHOR: {author}
    TITLE: {title}
    STATUS: Publish
    ALLOW COMMENTS: 2
    CONVERT BREAKS: br
    {categories}CATEGORY: {category_name}
    {/categories}
    DATE: {entry_date format='%m/%d/%Y %h:%i:%s %A'}
    -----
    BODY:
    {body}
    -----
    EXTENDED BODY:
    {extended}
    -----
    {embed="export/comments" the_entry_id="{entry_id}"}
    --------
    {/exp:channel:entries}

    Make a ‘comments’ template within the same ‘export’ template group. I used the following in the ‘comments’ template, but I did not enable PHP in the template since there is no PHP in the updated code as the original wiki article says to do.

    {exp:comment:entries channel="default_site" entry_id="{embed:the_entry_id}" sort="asc"}COMMENT: 
    AUTHOR: {name} 
    URL: {url} 
    DATE: {comment_date format="%m/%d/%Y %h:%i:%s %A"} 
    {comment} 
    ----- 
    {/exp:comment:entries}
    

    Now go view the index template by clicking the ‘view’ link in the control panel next to the ‘index’ template. It will generate a possibly very long ugly page. View source on that page and save the source. That’s your posts plus your comments in MT Export Format.

    Posted by John Morton on 02/07 at 03:59 PM
    DevelopmentNews • (0) CommentsPermalink
    Saturday, February 06, 2010

    Quick tip: Expression Engine Microformatted date

    I’m rebuilding SuperGeekery behind the scenes. Along the way, I will try to post little tidbits I think might be helpful along the way.

    I’ve spent the past 10 minutes formatting the dates for entries using microformats. That means wrapping the human-readable date that is displayed on a web site inside a <time> tag that is machine-readable. Here’s how you do that in Expression Engine.

    
    <div class="date">
    	<time datetime="{entry_date format='%Y-%m-%dT%H:%i:%s%O'}">
    		{entry_date format=' %M %j '}
    	</time>
    </div><!-- .date -->
    
    

    This code generates a machine-readable date of “2010-01-12T21:45:57-0500”, for example,  which is invisible to a human reading the web page. The person reading the page sees “Jan 12” only.

    One thing I’m not clear on is the time zone offset from GMT, the last bit of the machine-readable date. I’ve seen it use the offset with a colon, basically -5:00 instead of -500 mentioned. It looks like that would be accomplished by using {entry_date format=’%Y-%m-%dT%H:%i:%s%P’}, but it doesn’t seem to work on my development environment. Hmmmm.

    Posted by John Morton on 02/06 at 11:00 AM
    DevelopmentNews • (0) CommentsPermalink
    Tuesday, January 12, 2010

    Update On Building a Portfolio Site in Wordpress and the Plugins That Made It Work.

    Screenshot of TRÜF Creative

    Back in October 2009, I wrote about research I was doing about building a portfolio site with Wordpress. (Read that post here.) That post was inspired a project we were talking about doing at JMX2 at that time. Several months have passed and we’ve built the site I was initially researching. It’s live and I’m happy to finally share it with you. Check out the new TRÜF Creative site at http://trufcreative.com.

    (Note to WordPress folks: This turned out to be a long post, but if you’re interested in what plug-ins used in building the site, I do go over those in a bit.)

    The Front-end Design

    The site was beautifully designed by Monika Kehrer, the design director at TRÜF. She did a stunning job, IMHO. (You’ll see some new design from her here at SuperGeekery in the future as well. I’m finally going to give this baby a design overhaul!) Monika built the site with a 960 pixel grid in mind using the design templates you can download at 960.gs. If you’re designing a site, you could learn a lot from how accurately she’s built her Photoshop documents. (I may share those with you later. Perhaps ones from the SuperGeekery redesign.)

    Some of the things she had envisioned for the site didn’t seem possible using straight CSS though, so there’s some jquery helping out the design of the site. The obvious jquery pieces is the scrolling gallery on the home page. The less obvious jquery animation are the black rules that run off to the right hand side of the page. Their dimensions are recalculated whenever you resize the window in order to match Monika’s design. If you’re interested in how that happens, just go to the TRÜF front page and view source from your browser to check out the Javascript on the page.

    The Backend Design with Wordpress

    I’m very happy with the part of the site you don’t get to see as well, the admin panel. Primarily, the content of the site is a collection of portfolio pieces. This admin panel is customized specifically for the TRÜF site and the type of content needed for each portfolio piece.

    Here’s how the “post” page turned out for TRÜF. (This is in reference to the screenshot below.)

    1. An area to include as many graphics as needed for the main content area.
    2. An area for writing about the piece.
    3. Optional external link for each piece triggers a graphic on the portfolio piece’s page. If left blank, it doesn’t appear.
    4. A drop down list to select a thumbnail image for each piece.
    5. Optional radio buttons to have this piece included in the large rotating gallery images on the home page plus a drop down to select which image to use.
    6. The ability to reorder pieces via drag and drop.

    Sample of the admin panel
    (Click this image to view it full size on Flickr.)

    There's more to read. Click here for the rest. >>

    Posted by John Morton on 01/12 at 09:45 PM
    BloggingDevelopmentHow ToSoftwareTechnology • (1) CommentsPermalink
    Wednesday, December 09, 2009

    Same Origin Flash Security Kerfuffle For Web Developers Who Allow Uploads

    I’m a regular listener to Security Now!, the weekly TWIT podcast about security and privacy, primarily as it relates to being online. Last week’s episode #225 was about the ‘same origin policy’ issue.

    What is the Same Origin Policy?

    Wikipedia has a thorough write-up on same origin policy here, but I’ll give you the basics. It’s a matter of what files and processes trust each other on web sites. Basically, if files exist on the same domain, they are granted access to the same level of information.

    For example, since I wrote the code that made this page on SuperGeekery.com, I could have made a function that created a chunk of data based on your visit to the site (i.e. a cookie). I could then write a 2nd piece of javascript code that gets loaded into the original page that can access the 1st function’s data. My 2nd piece of code is granted access to that original piece of information because they are trusted by each other due to the fact that they live on the same domain. Your web brower enforces this rule.

    When would that 2nd piece of code not have access to the 1st function’s data? If my 2nd function was stored on a completely separate domain from http://SuperGeekery.com, it wouldn’t have access to the 1st piece of code’s data or functions because of the same origin policy. Smart, right? That’s done because web authors need to be able to keep information from leaking out.

    What the Kerfuffle? Part 1 - How the Flash Player works.

    The security blog, Foreground Security, has a detailed post called Flash Origin Policy Issues. Basically, Flash has the same basic rules as I described above. If a Flash file lives on the same domain as something else, it has access to all that same information.

    This should be fine because, for example, to get something onto my domain at SuperGeekery.com, you’d have to be me, right? And everything I write should be able to trust each other and share with each other. You may wonder if Flash Ads are a problem. Do they have this problem? No, there are Flash ads all over the internet, but since they are almost never hosted on the same server as the domain you’re visiting, they don’t get to access the data the web site’s primary code’s data. Cool.

    Oh, there is a problem in the Flash Player though I haven’t mentioned to you yet. The Foreground Security article nails it by pointing out that the Flash files “do not require a .swf extension or special content-type headers to execute.” Hmmm. What mischief could that lead to?

    Let’s look at an example. If I have a file that I call “mycat.jpg” on my server that’s not really a JPEG but actually a SWF file (a Flash file) and then I load “mycat.jpg” into this web page the Flash Player will execute it as if it’s a Flash file. That Flash file will have access to that 1st function’s data even though it appears to be a JPEG which shouldn’t have any ability to run any code. There’s a problem here.

    What the Kerfuffle? Part 2 - How the most CMS’s work.

    I’ve built sites using a variety of content management systems. SuperGeekery is Expression Engine behind the scenes. I love EE, by the way. I’ve also built WordPress sites, TextPattern sites and I’ve built ‘test’ Drupal sites, although none are live to outside users. In all cases, the default place for visitors to upload a file, say for their member profile photo, is on the same domain that the rest of the site is hosted on.

    All of them have some sort of upload checking built in. Basically, you can often limit the type of files to allow by checking the extension. (I haven’t tested all of this, but here’s a link to a post about this vulnerability in WordPress version 2.8.5 and lower.) If a file doesn’t end with the proper extension, it doesn’t get onto the server.

    That means if someone is able to upload a malicious Flash file to your site ‘disguised’ as a JPEG or GIF, it will be executed by the Flash Player unless you’ve not followed the standard way your CMS will store uploaded content from users. When anyone visits your site and that JPEG is displayed, it is trusted file being served from your domain and it’s a Flash file that has scripting ability. That’s trouble.

    What the Kerfuffle? Part 3 - Adobe’s response

    The real kerfuffle has been around Adobe’s response to the problem. One way to handle it seems like making all future versions of the Flash player only execute files that have the proper file extension. If it’s not a .swf file, refuse to run it. Adobe says the problem is not that simple though. I don’t know the full story so I have to believe them, but their response was posted in a blog post here. It sort of reads as if they’re saying it’s not their problem:

    If a site developer wants to host arbitrary uploaded content on a site and does not want SWF content to execute on their site, the SWF can be served with headers, which instruct Flash Player to treat the file as an attachment. Flash Player will acknowledge that request and present an Open/Save/Cancel dialogue to the user rather than render the content. Developers may also choose to limit uploads to only the types of content that they plan to support.  These steps to properly managing user-generated active content uploads may be challenging, but good web security requires vigilance against this type of risk alongside all the other familiar web threats like CSS, CSRF, ...

    So Adobe doesn’t really seem to want to fix this problem. It’s the web master’s problem. Interestingly, Foreground Security points out in another post that http://www.adobe.com, http://www.acrobat.com, http://www.photoshop.com, and other Adobe web properties all suffer from letting users upload images that “are not validated fully, and are stored on (and executable from) api.photoshop.com” and their domain policy allows them to be executed. I guess it is hard to do properly.

    Adobe, take on this problem.

    This is a tough problem for everyone involved. It’s tough for web developers. It’s tough for Adobe. It’s tough for users. Don’t you just wish people wouldn’t do malicous things?

    It’s vitally important for Adobe to hit this problem hard and come up with a fix even if they don’t consider themselves as responsible for the problem. The last thing I want to have as the response to this problem is to have users across the web start to uninstall the Flash player on a mass scale because Adobe has chosen to punt on this issue. I and many people I know make our livings relying on Flash as a tool to deliver rich media online. If web users choose to uninstall Flash because they feel threatened by having it on their machine, it threatens the entire ecosystem built around Flash. Adobe, that’s bad for all of us.

    Posted by John Morton on 12/09 at 04:21 PM
    DevelopmentFlashInternetNewsPrivacySecuritySoftwarePermalink
    Tuesday, November 24, 2009

    Cyber security watch-list for Black Friday 2009

    I get a fair number of press releases sent to SuperGeekery pushing products. I don't mention them very often though simply because this is my labor of love, not just my labor. grin

    I received one today from F-Secure with their prediction of the most likely searched terms for cyber scams for holiday shoppers. I think it's a pretty smart move on their part and a smart thing for people who shop online to be aware of. As I write this, it's just a few days before the start of the holiday shopping season for 2009. The economy sucks but people will still want to buy gifts. To save money, many will turn to the Internet and the cyber bad guys will be waiting. 

    So, without further build up, here the list of terms that F-Secure predicts the bad guys will try to lure you in with:

    • The popular video game Call of Duty: Modern Warfare 2
    • Merchandise related to the Michael Jackson film This Is It
    • The Flip UltraHD Camcorder
    • Apple’s iPod
    • Nintendo’s Wii
    • Playskool’s Chuck My Talking Truck

    If you're entering any of these into search engines this season, be especially skeptical of the links you click. If you're feeling uncomfortable about buying that Wii for $25, just shut your browser window.

    F-Secure has a page that gives a decent overview of what to look out for when shopping online or just simply searching. You can visit it here. Be warned. They're trying to sell you their software which I have not used. The article's got some good advice though.

    The most important bit of info is this, which I'll quote directly from that article. "You should also rely on ecommerce sites you trust and use the search inside the site for more reliable results."

    Remember when shopping online, if it's too good to be true. It's probably too good to be true. Be safe out there.

    Posted by John Morton on 11/24 at 07:18 PM
    InternetSecurityPermalink
    Page 1 of 25 pages  1 2 3 >  Last »