I never thought about lazy functions in JavaScript. Apparently, you can implement it this way:
var foo = function() {
var t = new Date();
foo = function() {
return t;
};
return foo();
};
I hate JavaScript.
Tag Archive for 'JavaScript'
This is crazy. MiniBuilder — AS3 editor built with AS3 and mod_actionscript — Apache mod to run AS3 server-side scripts. Both look like funny toys to play. I hate PHP, I wonder if there are good JS server-side solutions. Yes, JavaScript or ActionScript1. AS3 is too complicated for simple things.
I know that several multiuser servers use ActionScript1 as server-side programming language, but I’d use it like PHP. Just plain AS1 please.
… says computerworld.com.
This wouldn’t be funny if it was 100% true. I found this link (and this link) at a Russian IT community where the majority of people doesn’t really like Flash. So if they see “flash” and “flaw” in a topic title they usually behave like Pavlov’s dogs. I saw a lot of comments that Flash sucks, that it’s good time to install flash-blocking plugins and start using Silverlight or Java. But it seems nobody really knows what is going on.
- This is actually not a bug
- This is not a Flash specific flaw
- This is a really old vulnerability
But nooo, people keep running around screaming and cursing Flash.
This is so funny reading you guys. You don’t know much about the subject but keep making weird conclusions. During his or her life a person once understands that “you sleep better if you know less” (there should be an English proverb like that). If you are saying that this is a “fundamental flash bug” you might not know that it is not even a tip of an iceberg.
If you spend half a day googling and reading books you might find out that danger is actually everywhere, you just don’t know about it assuming that all hardware and software is flawless. Well, this “flash” vulnerability is just one in the huge family of Cross-site Scripting vulnerabilities. There were a lot of them found and a lot of them are still hiding within your favorite browsers. Everything executed on client side is vulnerable to XSS attacks. The most common technology is JavaScript, almost every other attack involves JavaScript too, like using it to retrieve sensitive data from Flash, Java or Silverlight.
So, how does it work? An XSS attack is done using a vulnerability in client software which allows an attacker to inject malicious code into client’s trusted zone and execute it. Security system thinks that if this code is executed from example.com it is trusted and can have access to all data associated with this domain.
How is this related to Flash? This is related to Flash as much as it is to every other client-side technology, computerworld just took one and started blaming it. So, I somehow upload my SWF to example.com. If it allows me to upload SWFs of course. If it doesn’t I can either rename it to something else or join with something else, apparently Flash Player can load a file of any extension placed in src attribute of embed tag. Anyway, if this SWF goes into /uploads folder of example.com it is considered to be trusted, because someone long time ago assumed that if a file is within public access of a domain it could be uploaded there only by that domain’s admin, which is not usually true as we see. This SWF now has access to everything related to example.com via JavaScript. This would be really stupid to display it without allowscriptaccess=never on example.com itself. But the article above says that this SWF is loaded with an external link not from example.com. For example, someone pretending to be your friend John sends you a link which points to this SWF being loaded from example.com where you are logged in right now. Congratulations, the SWF just stole your cookie.
If I’m not mistaken, this vulnerability can be easily fixed if user uploaded content is kept on a separate subdomain.
This is not related just to Flash. As you see a lot of JavaScript is involved. And you definitely can do the same using Java. But what’s more, as I said there are ways to bypass server’s uploading restrictions. For example, it’s possible to combine GIF and JAR (it’s actually a ZIP file) or PDF and JAR into one file so it looks like a perfect GIF (PDF) and can be executed as a perfect JAR. Did you know that? Did you know that there are still a lot of vulnerabilities in your favorite browsers? I don’t even want to mention HUGE number of sites made by newbies which have absolutely no security, they allow SQL injections and XSS JavaScript Injections. And you trust them your private information and credit card numbers? Did you know that it’s even possible to trick Google and find out your password? Did you know that saved passwords in Firefox can be retrieved by hackers too?
Did you know that these are not even 1/10 of all vulnerabilities? But why have nobody hacked you yet? Probably someone already did, you just don’t know that. Or nobody is interested in you.
How is this related to Flash? This is not Adobe’s fault. Of course they can come up with something involving crossdomain.xml and even more restrictive policies, but you can just upload your own crossdomain.xml to example.com as you did with your SWF. This is not again Adobe’s flaw. This is probably because in the beginning of Internet all basic protocols were not designed with security in mind. And now people invented new ones and upgraded old ones fixing leaks here and there.
Sites owners must develop their projects with security in mind and not just blame Flash. This is stupid.
And the last one. I actually USED this vulnerability long-long time ago against one of Flash discussion boards. Once again, this is not new!
By PDF support I mean possibility to show and generate PDF files in Flash/AIR.
Show.
Flash and Flex can’t work with PDF files. Period. The only way to show a PDF file (without converting it to any other format) is using an HTML wrapper. For Flex there’s Flex iFrame library. You can use it to show an HTML code with embeded PDF file with installed Adobe Reader plugin (assuming that it IS installed in the system). If you are publishing to AIR you can use HTMLLoader to do the same thing:
var request:URLRequest = new URLRequest("http://www.example.com/test.pdf");
pdf = new HTMLLoader();
pdf.height = 800;
pdf.width = 600;
pdf.load(request);
container.addChild(pdf);
Read more about it.
Once again this method relies on Adobe Reader plugin installed. But here you at least can check if the plugin is installed or not using HTMLLoader.pdfCapability. Though there’s a bug, if you install Adobe Reader plugin and don’t agree with Terms of Use pdfCapability shows OK but you will not be able to see your PDF document. What’s more this method comes with a huge list of limitations (quoted from the link above):
- PDF content does not display in a window (a NativeWindow object) that is transparent (where the transparent property is set to true).
- The display order of a PDF file operates differently than other display objects in an AIR application. Although PDF content clips correctly according to HTML display order, it will always sit on top of content in the AIR application’s display order.
- PDF content does not display in a window that is in full-screen mode (when the displayState property of the Stage is set to StageDisplayState.FULL_SCREEN or StageDisplayState.FULL_SCREEN_INTERACTIVE).
- If certain visual properties of an HTMLLoader object that contains a PDF document are changed, the PDF document will become invisible. These properties include the filters, alpha, rotation, and scaling properties. Changing thse renders the PDF file invisible until the properties are reset. This is also true if you change these properties of display object containers that contain the HTMLLoader object.
- PDF content is visible only when the scaleMode property of the Stage object of the NativeWindow object containing the PDF content is set to StageScaleMode.NO_SCALE. When it is set to any other value, the PDF content is not visible.
- Clicking links to content within the PDF file update the scroll position of the PDF content. Clicking links to content outside the PDF file redirect the HTMLLoader object that contains the PDF (even if the target of a link is a new window).
- PDF commenting workflows do not function in AIR.
This basically means that you can’t do anything with the box where your PDF is displayed, neither animate nor control it. It’s just sitting there messing with your cool AIR app.
But using this method you can communicate with a PDF file provided that you compile specific JavaScript in it using Adobe Acrobat JavaScript capabilities (doh?). Read further to find out how it can be done without Acrobat. I don’t know what JavaScript code inside PDF file can do, even if it has total control over the plugin this method sucks.
Convert to SWF.
More popular way is to convert PDF to SWF and load it in your application. The only open source tool I found is pdf2swf (part of swftools). Apparently it is used by every service which makes flash PDF viewers like scribd.com, safaribooksonline.com, pagegangster.com and alike. I actually found out about safaribooksonline when I was looking where to download AIR 1.5 Cookbook because there’s a chapter about PDF in AIR (which actually said nothing more that what I wrote here). Safari and PageGangster don’t secure their files but I couldn’t break Scribd data format. I know that it’s using pdf2swf because swftools home page mentions it.
This tool indeed converts PDF files to SWF. The latest version publishes to AVM2 with -T9 flag which you can use in AS3. It generates a lot of StaticText objects which of course are not TextFields but you can use TextSnapshot to work with StaticTexts (get text, select text). It does have conversion glitches, for some reason it may convert text to bitmaps instead, I can’t get how exactly it works with fonts. The latest version has a lot of bugs fixed but on my tests I failed making Flex select text with TextSnapshot. I’m waiting for a reply in mailing list.
The tool works, bad news is that you need to run it to convert PDF files to SWFs. That’s one more step in the chain.
Generate.
The most popular library for generating PDFs from ActionScript 3 is definitely AlivePDF. The project is active and many enthusiasts develop different extensions: templates, JavaScript injection (this is how you probably can inject JavaScript to any PDF file without Adobe Acrobat and use it to communicate with that file). The latest news is plans for using Alchemy to speed up PDF creation. There are a couple more projects on Google Code: PDFCase — a port of Java PDFJet and as3-pdfreader — a Chinese guy tried to port Jave PDFBox but gave up in the middle. So, we are left with the only solution — AlivePDF.
I don’t know all possibilities of AlivePDF so I can’t really tell how well it works. But at least it seems that there’s one working library for creating PDFs in ActionScript3.
Final words.
That’s a shame that PDF files can work with Flash content but ActionScript can’t work with PDF files. I’m not counting HTML wrapped PDF display in Flex/AIR. We need API at least for reading PDF content and displaying it on the screen. With ability to index and search text, add annotations and handle button events.
I was hoping that in the next Flash Player we’d get such API, but no, looks like we will have to wait longer.
Recent Comments