[erlang-questions] Two beautiful programs - or web programming made easy
Edmond Begumisa
ebegumisa@REDACTED
Thu Feb 17 18:34:45 CET 2011
On Thu, 17 Feb 2011 19:04:13 +1100, Joe Armstrong <erlang@REDACTED> wrote:
> On Thu, Feb 17, 2011 at 5:26 AM, Edmond Begumisa <
> ebegumisa@REDACTED> wrote:
>
>> I don't think you can control the size of spans in that way. Spans are
>> non-replaced inline elements, so they have no width or height
>> properties...
>>
>> http://www.w3.org/TR/CSS2/visudet.html#the-width-property
>> http://www.w3.org/TR/CSS2/visudet.html#the-height-property
>>
>> Though Mathias and David have indicated web-presentation isn't designed
>> for
>> this, I have seen people pull this kind of thing off with client-side js
>> trickery (don't remember where exactly, I think it was one of those AJAX
>> word-processors), but it went something like this...
>>
TYPO: That sentence should have started "Though *as* Mathias and David
have indicated web-presentation isn't designed for this..."
Missing word made it sound like I was saying they were wrong. Sorry Sirs.
>> * Create an invisible DIV with the width property set to DIV "a" but the
>> height property set to "auto"
>> * Give invisible DIV the appropriate typography settings with which you
>> want to measure (font, font-points, etc).
>> * Populate invisible DIV a with your text. DIV should expand downwards
>> to
>> fit the text.
>> * Loop, removing say 100 characters from the invisible DIV until it's
>> height is smaller than div "a"
>> * Now loop adding 1 char back til invisible DIV's height is larger than
>> DIV
>> "a"
>> * You've now found your sweet spot.
>> * Put those chars less one into DIV "a"
>> * Put the rest into DIV "b"
>>
>>
> http://stackoverflow.com/questions/118241/calculate-text-width-with-javascript
>
> Which seems to answer my question.
>
> Now I think I've got enough to write a decent in-browser editor that gets
> quotes right.
>
> <aside> why do in-brower editors not do quotes correctly? + the start
> quote
> and end quote
> symbols are *different* - if anybody knows of a javascript in-browser
> text
> edit thats gets quote
> right please tell me.</aside>
Forgot to mention: Ample sdk is pretty cool. Has a bunch of cross-browser
stuff you might be interested in like SVG and, HTML 5 Canvas would you
believe, XUL (in IE/Opera/Chrome)
http://www.amplesdk.com/
- Edmond -
>
> /Joe
>
>
>
> IIRC, the algo was optimised not to start with the entire text, but take
> a
>> reasonable guess based on the size of DIV "a". It's ugly but I remember
>> being surprised how well it worked.
>>
>> - Edmond -
>>
>>
>>
>>
>>
>>
>>
>> If I could do this I could easily port erlguten to run in a browser
>>>
>>> All these seem like pretty basic things - but I can't seem to find any
>>> code
>>>
>>> /Joe
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> That's the same reason why you might want things like Erlang handling
>>>>
>>>>> Erlang parsing, SQL handling its own escaping, etc. If you generate
>>>>> and
>>>>> send JS as one over the wire, you will have to double-check it
>>>>> server-side.
>>>>>
>>>>>
>>>> How about adding templating? (I suggested this to Joe off-list)...
>>>>
>>>> One could possibly use leex/yecc to compile say "std.tpl" file and
>>>> access
>>>> it from Erlang code like so...
>>>>
>>>> Pid ! {insert, std.grid(List)}
>>>>
>>>> which might use the content of std.tpl to produce...
>>>>
>>>> Pid ! {insert, <<"<table>blah blah</table>">>) % Or
>>>> <<"createElement(blah)">>
>>>>
>>>> which might then stream to the client...
>>>>
>>>> "document.body.innerHTML("<table>blah blah</table>") /* Or
>>>> createElement/or jQuery insert call */
>>>>
>>>> The nice thing with this is, std.tpl could have versions.
>>>>
>>>> Joe likes SVG: so his std.grid(List) might produce some fancy SVG
>>>> code.
>>>> I like XUL: so my std.grid(List) might produce "<grid>blah</grid>"
>>>>
>>>> Templating might be extendable, so you might have an app specific
>>>> my.tpl
>>>> which extends on std.tpl...
>>>>
>>>> so when you: Pid ! {new, my.wnd(..)}
>>>>
>>>> the client gets a new page with stylesheet references, script tags,
>>>> etc,
>>>> specified in the my.tpl
>>>>
>>>> With all the great minds on this list, surely suggestions could be
>>>> made
>>>> to
>>>> turn this early one-paged code into something more and more useful??
>>>>
>>>> - Edmond -
>>>>
>>>>
>>>>
>>>> Unless you're running with node.js, that's going to be annoying for
>>>> no
>>>>
>>>>> good reason.
>>>>>
>>>>>
>>>>
>>>> For CSRF, There is likely no incidence at all. It's a question of
>>>> shared
>>>>> data between the server and HTML forms. How that data gets there is
>>>>> not
>>>>> really important at first. I could be wrong on that one though and it
>>>>> might
>>>>> be worse than what I expect. For SQL injection, it's all about the
>>>>> last
>>>>> line
>>>>> of defence before sending the data to your DB engine. If you treat
>>>>> it in
>>>>> JS,
>>>>> God have mercy on your application.
>>>>>
>>>>> But yeah, this little security roundup was again to comment on the
>>>>> 'encrypting your JS' is what you need comments. There's a safety
>>>>> element
>>>>> to
>>>>> using eval, and also performance, clarity and semantic concerns to be
>>>>> had.
>>>>>
>>>>> - Edmond -
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, 14 Feb 2011 23:43:57 +1100, Frédéric Trottier-Hébert <
>>>>>> fred.hebert@REDACTED> wrote:
>>>>>>
>>>>>> On 2011-02-14, at 03:35 AM, Joe Armstrong wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Ok so "separation of concerns" is good but having different
>>>>>>>> notations
>>>>>>>> for expressing the concerns
>>>>>>>> is crazy- to make a web thing that interacts with a server you
>>>>>>>> need
>>>>>>>> to
>>>>>>>> learn something like
>>>>>>>>
>>>>>>>> HTML
>>>>>>>> Javascript
>>>>>>>> CSS
>>>>>>>> PHP
>>>>>>>> MySQL
>>>>>>>>
>>>>>>>> And to be able to configure Apache and MySQL - other combinations
>>>>>>>> are
>>>>>>>> possible.
>>>>>>>>
>>>>>>>>
>>>>>>> I can agree with that. To have a functional website, you do need to
>>>>>>> know
>>>>>>> a lot of different technologies. The web evolved organically and
>>>>>>> each
>>>>>>> part
>>>>>>> of the problem space had its own solution developed over time.
>>>>>>>
>>>>>>>
>>>>>>> Then you have to split the flow of control to many places.
>>>>>>>>
>>>>>>>> All of this is crazy madness. There should be *one* notation that
>>>>>>>> is
>>>>>>>> powerful enough to express all
>>>>>>>> these things. In the browser is seems sensible to forget about css
>>>>>>>> and
>>>>>>>> html only use Javascript
>>>>>>>> The only communication with the browser should be by sending it
>>>>>>>> javascript.
>>>>>>>>
>>>>>>>>
>>>>>>> There should, but there isn't. The truth here is that most
>>>>>>> programmers
>>>>>>> are awful at design. In any somewhat large setup, your backend
>>>>>>> programmers,
>>>>>>> your designers and your integrators (the guys just handling HTML,
>>>>>>> and
>>>>>>> CSS,
>>>>>>> maybe some Javascript) are not necessarily the same person.
>>>>>>>
>>>>>>> Right now the ring of web technologies is divided in a way that
>>>>>>> makes
>>>>>>> it
>>>>>>> somewhat simple to have different people from different background
>>>>>>> and
>>>>>>> knowledges to work on different part of your software. It makes
>>>>>>> sense
>>>>>>> to
>>>>>>> have the designer or integrator to be able to change the look and
>>>>>>> feel
>>>>>>> of a
>>>>>>> website without having to play in your code and maybe mess up
>>>>>>> database
>>>>>>> queries. Modern template engines in fact try to forbid all kinds of
>>>>>>> seriously side-effecting code (like DB queries) from happening in
>>>>>>> the
>>>>>>> templates.
>>>>>>>
>>>>>>> There should be no worry for your guy working in Javascript that
>>>>>>> he'd
>>>>>>> not need to suddenly learn Erlang to be able to debug your
>>>>>>> application.
>>>>>>> Then again, this separation of concerns allows specialists to work
>>>>>>> on
>>>>>>> their speciality with more ease. It makes things somewhat simpler
>>>>>>> in
>>>>>>> larger
>>>>>>> organisations, but quite painful for one-man operations. I'll tell
>>>>>>> you
>>>>>>> that
>>>>>>> it makes a lot of sense when you know all of the tools in the
>>>>>>> toolkit
>>>>>>> though
>>>>>>> :)
>>>>>>>
>>>>>>> How you generate the javascript is irrelevant - by hand or by
>>>>>>> program
>>>>>>> -
>>>>>>>
>>>>>>>> who cares. If you make it by
>>>>>>>> program the chances are that it's right.
>>>>>>>>
>>>>>>>> Yes and no. Generated javascript is nearly as old as the
>>>>>>>> language --
>>>>>>>>
>>>>>>> many, many .NET apps had that kind of things. Some editors like
>>>>>>> Dreamweaver
>>>>>>> could generate JS for you. One of the problem with this is that it
>>>>>>> was
>>>>>>> often
>>>>>>> pure garbage, or it wouldn't work in all browsers uniformly. If you
>>>>>>> can
>>>>>>> manage to generate and capture complex behaviours in a compliant
>>>>>>> manner, all
>>>>>>> the better. I have myself lost much hope with regards to that
>>>>>>> though.
>>>>>>>
>>>>>>> Security is orthogonal to this - send encrypted js over the wire
>>>>>>> and
>>>>>>>
>>>>>>>> make sure your key-rings are secure
>>>>>>>> this is a completely different problem.
>>>>>>>>
>>>>>>>>
>>>>>>> This is only transmission security. Encryption has nothing to do
>>>>>>> with
>>>>>>> Cross-Site Scripting (XSS, where some user is able to run
>>>>>>> arbitrary JS
>>>>>>> in
>>>>>>> your page for you and ends up stealing information), Cross Site
>>>>>>> Request
>>>>>>> Forgery (CSRF, where the attacker uses the fact your application is
>>>>>>> forgetting about things like the origin of the queries to hijack
>>>>>>> the
>>>>>>> client's session in their place. This is related to Same Origin
>>>>>>> Policy
>>>>>>> issues and not easy to handle), SQL injection, overwriting some
>>>>>>> parameters
>>>>>>> because you don't fetch them in the right order server-side (see
>>>>>>> problems
>>>>>>> with the $_REQUEST variable in PHP), etc.
>>>>>>>
>>>>>>> 1. XSS
>>>>>>> XSS is, as mentioned above, the ability to run abritrary JS on a
>>>>>>> page.
>>>>>>> This is the risky thing with your eval.
>>>>>>> http://en.wikipedia.org/wiki/Cross-site_scripting contains many
>>>>>>> details
>>>>>>> on understanding the related issues. It's not always a simple
>>>>>>> matter
>>>>>>> of
>>>>>>> escaping. Some more advanced attacks even rely on string encoding
>>>>>>> to
>>>>>>> make
>>>>>>> sure your escaping fails. See
>>>>>>> http://www.governmentsecurity.org/forum/index.php?showtopic=18105.
>>>>>>>
>>>>>>> 2. CSRF
>>>>>>> CSRF is a tricky thing. Because HTTP doesn't support sessions, over
>>>>>>> the
>>>>>>> years, the guys from Netscape (back then) or Opera (or whoever)
>>>>>>> ended
>>>>>>> up
>>>>>>> using Cookies to share data on every query. What happens there is
>>>>>>> that
>>>>>>> on
>>>>>>> every query the browser sends to a server, it also packages the
>>>>>>> cookies
>>>>>>> neatly in the headers -- no matter what page you were on when they
>>>>>>> were
>>>>>>> sent. The issue here is that the server might not check from what
>>>>>>> page
>>>>>>> the
>>>>>>> call is coming from.
>>>>>>>
>>>>>>> Basically, if twitter had an URL call such as
>>>>>>> http://twitter.com/tweet/add?message=SomeMessageHere that would
>>>>>>> automatically add a tweet from your account and I put that link in
>>>>>>> an
>>>>>>> image
>>>>>>> tag on some site, every time you would load that image, you would
>>>>>>> automatically make a call to the server, your browser sending in
>>>>>>> your
>>>>>>> cookies and making it look like YOU actually made that call, even
>>>>>>> if
>>>>>>> you
>>>>>>> didn't know. In this case, the request is especially easy to do
>>>>>>> because
>>>>>>> twitter would be using GET parameters to have side-effects on the
>>>>>>> server. By
>>>>>>> forcing people into using POST, you can make things harder, but not
>>>>>>> impossible.
>>>>>>>
>>>>>>> One way to work again POST is using a fake website -- let's say I
>>>>>>> use
>>>>>>> learnyousomeerlang.com. On my own site, I'll be putting a fake
>>>>>>> javascript form inside an iframe (so that the page doesn't refresh
>>>>>>> when
>>>>>>> submitted) and have the script automatically send in the POST form.
>>>>>>> Now I
>>>>>>> send the link to my trick page over twitter and everyone who
>>>>>>> clicks on
>>>>>>> it
>>>>>>> from there will be guaranteed to have their session open and
>>>>>>> sending
>>>>>>> in
>>>>>>> data. I've in fact used this trick to have the site owner at my old
>>>>>>> job to
>>>>>>> close his own admin account on his own website so he could realise
>>>>>>> the
>>>>>>> importance of the threat.
>>>>>>>
>>>>>>> How can you solve this one? Well there are a few ways -- for one
>>>>>>> you
>>>>>>> could check the HTTP referrer, but that won't work everywhere -- if
>>>>>>> you
>>>>>>> expect calls from flash, it doesn't always send these elements of
>>>>>>> the
>>>>>>> HTTP
>>>>>>> header. In the case of HTTPS, depending on how you handle things,
>>>>>>> the
>>>>>>> header
>>>>>>> might not always be sent either so you can't know for sure. Better
>>>>>>> than
>>>>>>> that, if I'm using the <img> trick on your own website (on twitter,
>>>>>>> for
>>>>>>> twitter users), the domain will be the same, without you being
>>>>>>> able to
>>>>>>> check
>>>>>>> for anything.
>>>>>>>
>>>>>>> The only foolproof way to do this is to use what they call
>>>>>>> 'tokens':
>>>>>>> each call you make to the server has to have a unique piece of data
>>>>>>> that the
>>>>>>> server knows about that can prove that the call you just made comes
>>>>>>> from
>>>>>>> you, but also from your own forms on your own websites. These
>>>>>>> tokens
>>>>>>> should
>>>>>>> have an expiration time and be hidden from plain view, submitted
>>>>>>> automatically with any form. If you don't have this, your
>>>>>>> application
>>>>>>> might
>>>>>>> not be safe.
>>>>>>>
>>>>>>> This has *nothing* to do with encryption, and everything to do with
>>>>>>> not
>>>>>>> understanding the potential threats of the web correctly. It is an
>>>>>>> application-level issue, much like XSS is. And it's pretty damn
>>>>>>> important.
>>>>>>>
>>>>>>> 3. SQL injection is a different beast, where you do not properly
>>>>>>> escape
>>>>>>> the parameters of a request going to the database, letting your run
>>>>>>> arbitrary DB calls. Erlang with Mnesia doesn't have to worry about
>>>>>>> that, but
>>>>>>> Erlang with any SQL has to, even if you end up using QLC (it
>>>>>>> depends
>>>>>>> on the
>>>>>>> library at the back in this case though, and is generally safe
>>>>>>> enough).
>>>>>>> http://en.wikipedia.org/wiki/Sql_injection has sufficient details.
>>>>>>>
>>>>>>> 4.You have to consider that sometimes these attacks are combined
>>>>>>> together to be able to really do damage.
>>>>>>>
>>>>>>> I haven't even covered using weak hashing for passwords, bad
>>>>>>> security
>>>>>>> policies on cookies, opening files on dynamic paths without
>>>>>>> filtering
>>>>>>> the
>>>>>>> input, etc.
>>>>>>>
>>>>>>> Web application security is not a joke and it's certainly not easy.
>>>>>>> It's
>>>>>>> a very serious thing and most developers get it wrong at one point
>>>>>>> or
>>>>>>> another. Wordpress got it wrong, Twitter got it wrong, facebook
>>>>>>> got it
>>>>>>> wrong, Google got it wrong, and so on, even though they're
>>>>>>> supposed to
>>>>>>> be
>>>>>>> leaders in the field. Most of them got it wrong more than once too.
>>>>>>> This is
>>>>>>> why I kind of support a 'paranoid' line of thought.
>>>>>>>
>>>>>>> --
>>>>>>> Fred Hébert
>>>>>>> http://www.erlang-solutions.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Using Opera's revolutionary e-mail client:
>>>>>> http://www.opera.com/mail/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>>>
>>>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the erlang-questions
mailing list