Course Vector

Notes: Flash 9 Gotchas/Bugs

This is also migrated over from labs. This was a list of bugs and gotchas I’ve run into over during my time as a Flash developer. I’m sure the best play to look would be Adobe’s Bug tracker but it doesn’t hurt to have a concise list of things to watch out for.

Bugs/ Gotches

• Bug

  wmode="opaque" or "transparent" disables KeyDown actions (not true in 9,0,60,0 beta) and disables MouseWheel actions

› Continue reading

Black Box – Flash Secure Login

Description

BlackBox is a Flash-based login application. We built this much for the same reasons Comet was. We didn’t have anyway of doing a secure (read SSL) connection so we made our own next best thing. Whats funny is that in the end, the method we “ingeniously” came up with is almost the exact same method used with POP servers to send email.

This is an older project pulled from Labs and is currently password protected. This might change later, it might not. I wouldn’t hold your breath on this. This was made becuase a friend of ours worked at a company that didn’t allow any IM programs and we were too cheap to setup a server.

Features

• Secure login – Session based
• Easy to setup

› Continue reading

Comet – Flash-Based Chat

What’s New

• New black theme

Description

Comet is a Flash-based chat application. It is a stand-alone application and does not require a server application in order to function. It does require PHP 4+ to function though.

This is an older project pulled from Labs and is currently password protected. This might change later, it might not. I wouldn’t hold your breath on this. This was made becuase a friend of ours worked at a company that didn’t allow any IM programs and we were too cheap to setup a server.

Features

• Muli-user chat without backend server
• Easy to setup
• Secure login

› Continue reading

About the Labs Wiki

The Labs Wiki was originally meant to showcase all of our projects and anything else we found interesting. But I think we’ve had greater success with this as a blog format. With this said, and to reduce redundancy, I’m going to start clearing out the wiki and moving any unique content here to the blog. This was a long time coming, since the blog I haven’t really updated anything on the wiki anyways. So this just makes sense.

So expect to see some more details popping up on the projects pages and maybe a few more posts. Enjoy!

Notes: Cross-Domain Policy

Below is the structure of the cross-domain policy and all the allowed values. The majority of the content was aggregated from Adobe’s page on cross-domain policies.

A cross-domain policy file is an XML document that allows a web client to handle data across multiple domains. You will usually need one if the SWF is playing on Domain A and the files are located on Domain B. Policy files grant read access to data as well as permit a client to include custom headers in cross-domain requests. A policy file is also used when using Sockets during socket-based connections.

The most common location for a policy file on a server is in the root directory of a domain with the filename crossdomain.xml (e.g. http://example.com/crossdomain.xml)—the default location that clients check when a policy file is required. Policy files saved this way are known as master policy files. The following is an example of a typical, permissive URL (i.e. non-socket) master policy file:

Example

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>
	<site-control permitted-cross-domain-policies="master-only"/>
	<allow-access-from domain="*"/>
	<allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>

› Continue reading