midnite
-
Posts
179 -
Joined
-
Last visited
midnite's Achievements
Member (2/7)
1
Reputation
-
In the image attached below, in the (3) light blue content assist box, on the left there are 5 Firefox browser icons. What do they mean? Seemingly they mean those methods are only supported in Firefox. But of what versions? And if a certain element is supported in both Firefox and Chrome, but not IE, how will it show (as there is only 1 column space for 1 icon)? (image from http://www.jetbrains.com/phpstorm/webhelp/familiarize-yourself-with-phpstorm-editor.html) On the other hand, in Aptana, there are different columns of browser icons, showing levels of support by light up or not. (image from http://aptana.com/products/studio3) In addition, in the description area, detailed browser versions of support is also shown. (image from my test of Eclipse + Aptana plugin) If one asks why dont i just use Aptana, and forget about PHPStorm? As there are some significant drawbacks while coding JS in Aptana, and some says Aptana browser version support is not worth trusting. That's why I am looking for different IDEs. In conclusion, how to understand browser icons in PHPStorm content assist?
-
Thanks DaveJ. Yes it is tricky for both PHP and JS, as the classes are not really related to the files. I have tested for a few versions of Eclipse. Most of them can cross-files reference PHP. But when it comes to JS, it depends (will be explained later). While testing different IDEs, i particular like the Aptana or the Eclipse with the Aptana plugin, which it provides "level of support for each element in the major web browsers" in its content assist (works for both PHP & JS): (Does Netbeans have this?) Let me sidetrack a bit. As fas as i know, there are 3 ways to define classes (objects) in JS: A) using var o = {} var o = { field: "..."; method: "function() { /* ... */ }} using function() {} function f() { this.field = "..."; this.method = function() { /* ... */ };} C) using var a = function () {} var a = function () { this.field = "..."; this.method = function() { /* ... */ };}; However, neither Aptana nor Eclipse with Aptana plugin can cross-files reference objects defined by method B and C. Both of them only work for method A. On the other hand, Eclipse with the JavaScript Development Tool (JSDT) plugin, or Eclipse with the PHP Development Tool (PDT) plugin, they only work for method B and C. In addition, they cannot show browser version support in the content assist (as they are not Aptana). As a result, i have to use both Eclipse + Aptana and Eclipse + JSDT for a complete function. Using two IDEs at the same time is not convenience. In conclusion, a perfect IDE for me would be: Cross-file reference for both PHP and JavaScript (for all methods #A #B #C). Showing browser version support in the content assist. (1 would be the priority, 2 is the second most important though.) Note that, in my tests, no Eclipse version can satisfy #1.
-
Thanks DaveJ. What am I looking for is exactly the feature you mentioned in your first paragraph. Yes it seems to be a must-have feature for every Java IDE. But for PHP and JS, some IDE cannot do this. They can only look up the class definition within the same file.
-
Thanks DaveJ for reply. What do you mean? In fact I can code well in Notepad++ or even Notepad. But as I would like to make my JS and PHP go OO, build some objects like i did in Java, an IDE with cross-files referencing would be very very handy (esp eliminate many misspells).
-
dsonesuk, thanks for reply! Do you think using position: relative; and overflow: auto; can effectively restrict all the elements visually inside div#jail?
-
dsonesuk, i used overflow: hidden; to visually hide elements going outside the #jail. In your examples, you used overflow: auto; (which i found it is even better as it adds the scroll bars if necessary) that can also prevent HTML goes visually outside the #jail. Do you think it is enough?
-
Thanks again for your reply. Do you think if i use a position: relative; div#jail, and ban the use of position: fixed, I can visually keep everything inside the div#jail?
-
Thanks dsonesuk for explaining about the governing elements. I have a question. In my simple test below, for a position: absolute; inner element, in addition to being governed by a position: relative; outer element, it can also be governed by a position: absolute; outer element. Isn't it? <html><head><style>#outer { position: absolute; overflow: auto; border: 1px dotted red; height: 200%; width: 50%; left: 25%; top: 25%;}#inner { position: absolute; top: -10px; right: -10px;}</style></head><body><div id="outer"> <div id="inner"> just a line of text </div></div></body></html> However, I do agree that, if both position: relative; and position: absolute; can be used to govern the inner elements, using position: relative; would be a better choice, as it is more friendly to other elements in the webpage. Secondly, do you mean that position: fixed; "reports" only to the browser window outer edges, thus position: fixed; elements can always breakthrough (ignore) its outer element(s)? I guess I didn't state my question and objective clear enough in the first post. [*]I will have a <div id="jail"></div> in my webpage.[*]Inside the <div id="jail"></div>, I will load the user-supplied (X)HTML codes.[*]To prevent XSS, those user-supplied (X)HTML codes will be sanitised by HTML Purifier.[*]I will allow also user-supplied CSS for adding styles to their elements. [*]To avoid user-supplied CSS messing up with my elements, all user-supplied CSS will be prefixed with #jail.[*]My objective is to add certain styles to <div id="jail"></div> (or using any other approaches) such that no user-supplied content will be displayed outside <div id="jail"></div>. Thanks dsonesuk again for your help. Do you have any ideas?
-
Thanks @justsomeguy for providing this reminder that XSLT will cause DoS and XSS. In addition, some others also say that XSL is Turing Complete that can do anything to harm the server and scripts. In addition, I would have to avoid the Billion Laughs attack in XML too. I guess I have to modify my step (1) to: [*]User submits a piece of XSL code XHTML code with my special tags - for example, I allow [for-each], [choose], [when], etc.[*]As they are in fact a white-list of XSLT tags, then i validate and replace those tags with actual XSLT tags.[*]In the server, there are some sample data (sample XMLs). PHP is used to do the XSL transform with those sample XML data.[*]Pass the output XHTML to HTML Purifier. If HTML Purifier detects any prohibited elements in the code, stop process and show the errors to user.[*]If it passes HTML Purifier, check it against the W3C validator. (This is just a double check. Outputs from HTML Purifier should be valid.)[*]Save the piece of XSL code into database. Use (include) it whenever needed. For the sample test cases, I will include as many special cases as possible.
-
I am going to design a webpage, which contains <div>(s) that allow users to submit their (X)HTML with CSS, and being inserted into those <div>(s). I understand it will suffer from XSS seriously, so I will use HTML Purifier to sanitise the (X)HTML and CSS. For instance, I will definitely not allow <script>, <iframe>, and external resources. But I wish to allow almost all other tags and CSS attributes. Here comes the question. I wish to keep client elements (visually) inside the <div>(s). I have tried a partial solution, by using position: absolute; and overflow: hidden;, as follow: <html><head><style>div#jail { position: absolute; overflow: hidden; border: 1px dotted red; height: 200%; width: 50%; left: 25%; top: 25%;}/* All client's CSS is ensured prefixed with div#jail */div#jail .client_code { margin: 0; position: absolute; top: -8px; z-index: 1000;}</style></head><body><div id="jail"> <p class="client_code">elements being jailed</p></div></body></html>The effect of the codes above is as follow: The red dotted line is the "Jail". The purpose is to make any HTML codes with any CSS (prefixed with div#jail) to visually keep inside the box. As shown above, the line of text tried to move out of the box. However, because of overflow: hidden, it is just clipped. So nothing could escape the "Jail". This is good. So far, I have successfully jailed <p> inside div#jail for most kinds of client's HTML elements and CSS, except when user uses position: fixed;. div#jail .client_code { position: fixed; top: 0px;}The following is the screen capture, which the "jail" failed: As shown above, if the position: fixed CSS is applied to the jailed elements, the result is that the line of text can be shown outside the box - i call it a breakthrough of the jail. This is not good. So, my question is, how to ensure everything are visually "jailed" inside the box? If position: fixed is the only CSS which can cause this breakthrough, i can just prohibit position: fixed and the Jail would be enforced. If there are any other ideas/design to achieve this, any solutions are welcomed! Thanks a lot!
-
Thanks DaveJ, i know XSS would be a serious problem. That's why i will use HTML Purifier to sanitise the user-codes. Do you think it will be safe enough?
-
Thanks MarkT for willing to help. Here are the screenshots for the design illustration. Firstly, the red dotted line is the "Jail". The purpose is to make any HTML codes with any CSS (prefixed with div#jail) to visually keep inside the box. As shown above, the line of text tried to move out of the box. However, because of overflow: hidden, it is just clipped. So nothing could escape the "Jail". This is good. Secondly, if the position: fixed CSS is applied to the jailed elements, the result is that it can be shown outside the box - i call it a breakthrough of the jail. This is not good. So, my question is, how to ensure everything are visually "jailed" inside the box? If position: fixed is the only CSS which can cause this breakthrough, i can just prohibit position: fixed and the Jail would be enforced.
-
Thanks very much for reply. You may just cut and paste the codes above into the W3schools try it editors, you will understand it ;-)
-
I am going to design a webpage, which contains <div>(s) that allow users to submit their (X)HTML with CSS, and being inserted into those <div>(s). I understand it will suffer from XSS seriously, so I will use HTML Purifier to sanitise the (X)HTML and CSS. For instance, I will definitely not allow <script>, <iframe>, and external resources. But I wish to allow almost all other tags and CSS attributes. Here comes the question. I wish to keep client elements (visually) inside the <div>(s). I have tried a partial solution, by using position: absolute; and overflow: hidden;, as follow: <html><head><style>div#jail { position: absolute; overflow: hidden; border: 1px dotted red; height: 200%; width: 50%; left: 25%; top: 25%;}/* All client's CSS is ensured prefixed with div#jail */div#jail .client_code { margin: 0; position: absolute; top: -8px; z-index: 1000;}</style></head><body><div id="jail"> <p class="client_code">elements being jailed</p></div></body></html> So far, I have successfully jailed <p> inside div#jail for most kinds of client's HTML elements and CSS, except position: fixed;. div#jail .client_code { position: fixed; top: 0px;} So, is it ok to only block position: fixed;, and the jail would be tough and valid? If there are any other ideas/design to achieve this, any solutions are welcomed! Thanks a lot!That is, if users use CSS position: fixed;, their elements could breakthrough the jail:
-
In my webpage, I am going allow clients (X)HTML. To avoid XSS, I will use HTML Purifier, and disable the <script> tag (and some other dangerous tags). Yet I would like to enable designers of those (X)HTML to use certain programming-like features, for example displaying a list of items, which would need a for-loop. Then I came up with the idea that : users submit the XSL code, I provide the XML with the data required by the users. As HTML Purifier cannot sanitise XSL code (can it?), my proposed flow would be: [*]User submits a piece of XSL code.[*]In the server, there are some sample data (sample XMLs). PHP is used to do the XSL transform with those sample XML data.[*]Pass the output XHTML to HTML Purifier. If HTML Purifier detects any prohibited elements in the code, stop process and show the errors to user.[*]If it passes HTML Purifier, check it against the W3C validator. (This is just a double check. Outputs from HTML Purifier should be valid.)[*]Save the piece of XSL code into database. Use (include) it whenever needed. Do you think the flow above can assure the final XSL code saved into the database is clean (given that HTML Purifier is perfect)? Another concern is that, (this is the main question here), is it safe to accept arbitrary XSL codes, and perform XSL transform by PHP in the server? Could there be any security holes that some XSS, injection, etc being included in the XSL codes, such that being harmful to the server or the PHP programs? Finally, if there are any other ideas/design to achieve this, any solutions are welcomed! Thanks a lot!
