[webkit-help] WebKit authentication prompts even if http://user:pass at host used (Barry Scott)
haithem rahmani
haithem.rahmani at gmail.com
Tue Aug 3 00:24:19 PDT 2010
>
> Message: 1
> Date: Mon, 2 Aug 2010 15:26:49 +0100
> From: Barry Scott <barry.scott at onelan.co.uk>
> To: webkit-help at lists.webkit.org
> Subject: [webkit-help] WebKit authentication prompts even if
> http://user:pass@host used
> Message-ID: <201008021526.49857.barry.scott at onelan.co.uk>
> Content-Type: text/plain; charset="us-ascii"
>
> I'm seeing unexpected behaviour from WebKit when I ask for a URI with
> user and password in it to be loaded. The Soap "authentication" signal is
> issued.
>
according to the RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt) :
Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password)...
I don't know which webkit port are you using but for WebkitGtk based on libsoup
it's the normal behaviour, since libsoup is compliant to the RFC 3986.
regards.
Haithem.
>
> ------------------------------
>
> Message: 2
> Date: Mon, 2 Aug 2010 18:17:20 +0200
> From: Alex Vazquez <alexvazquezfente at gmail.com>
> To: demallien <demallien at me.com>
> Cc: webkit-help at lists.webkit.org
> Subject: Re: [webkit-help] Help with possible buffer overflow (JS
> code) in our DFB port
> Message-ID:
> <AANLkTimO1Tkgkzc2Kj=QuFUYe4Jgsuz3u4Hk_PWKEOf- at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 2010/8/2 demallien <demallien at me.com>
>
> > Alejandro,
> >
> > From the description of the bug, it sounds an awful lot like you are
> > calling into JSC from different threads. It's not clear from your post
> if
> > you can reproduce the bug when the code isn't all in the same file or
> not,
> > but I would be double checking that you haven't changed anything with
> > respect to when you call code.
> >
> >
> The bug is not reproducible if the JS code is distributed in several files
> and neither it is if the code is compressed.
>
>
> > It's not really clearly marked in the documentation, but each JSAPI call
> > that takes a JSContextRef as a parameter, needs all calls using that
> context
> > to be made from the same thread, otherwise you get random corruption of
> the
> > stack.
> >
> >
> Actually, we are not using JSAPI, we are running the JS code from web pages
> (we only use HTML + CSS + JS for the GUI) so we are not mixing calls from
> different threads explicitely. It could be that the javascript engine is
> behaving wrong, though, so we'll investigate that possibility.
>
>
> > Hope that helps,
> >
> > Alli
> >
> >
> Thank you for your help,
>
>
> > We are using a DirectFB port of webkit as GUI renderer on an embedded
> > device
> > (MIPS architecture).
> >
> > We use a lot of Javascript code and we are experiencing random crashes
> when
> > we bunch all that code in a single file without compressing it
> > (yui-compressor). We suspect that we have some kind of buffer overflow
> that
> > causes these random crashes since it almost never crashes on the same
> > point).
> >
> > It is hard to determine exactly which is the file size limit, if this is
> > the
> > case, because it seems different for each execution (the memory corrupted
> > may not be used for a long time) but we have reproduced the bug with a
> > Javascript file of 300 KB. Also, we don't know if the bug is platform
> > specific, architecture specific, etc ..
> >
> > Any idea of how to investigate this issue (source files where the
> > Javascript
> > files are read to memory, build variables/parameters that can affect this
> > behaviour, or any other idea) is welcome.
> >
> > Thanks and kind regards,
> >
> > --
> > Alejandro Vazquez Fente
> >
> >
> > _______________________________________________
> > webkit-help mailing list
> > webkit-help at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
> >
> >
>
>
> --
> Alejandro Vazquez Fente
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-help/attachments/20100802/99157b37/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 3 Aug 2010 11:20:31 +0800
> From: vizshala <vizshala at gmail.com>
> To: webkit-help at lists.webkit.org
> Subject: Re: [webkit-help] Capture rendering buffer (windows)
> Message-ID:
> <AANLkTimvF4jVJ5jpY4AweVyzHfis1A1iEDw9BFzsO86=@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi chris,
>
> I also noticed that in windowless mode ( transparent or opaque ), the CPU
> comsumption is more than window mode.
> In my machine with amd phenom quad-core 2.5GHz, playing youtube video in
> the
> window mode will comsume about 5% CPU resource while the windowless mode
> will double it to about 10%.
>
> At first I tried to capture the web view in windowless mode at the frame
> rate of 30 per second. The steps I took are as follows:
>
> 1. invalidate the backingstore :
> according to the NPAPI rule, the windowless plugin will call
> NPN_InvalidateRect to notify the browser that the plugin area is dirty.
> After PluginView got notified, it will invalidate the rect, finally WebView
> will add this rect to dirty region. So I use a UI Delegate to receive the
> dirty rect.
>
> 2. fetch the backingstore handle
>
> 3. copy bits by bitblt
>
> But the cpu usage is about 15%, performance is not acceptable. After some
> search, I found that the step1 is the performance hit. I think this is due
> to the updateBackingStore will go through the layout again.
>
> Is it possible to improve the performance? thx
>
> Regards,
> vizshala at gmail.com
>
>
> 2010/7/22 Chris Hatko <chatko at gmail.com>
>
> > Hey,
> >
> > I'm still not fully done. I've implemented a solution which forces
> > every flash plugin to run in windowless mode (force WMODE param).
> > Doing this gives the render control over painting and as long as i
> > invalidate the plugin area, and replicate some of the WM_PAINT
> > functionality the m_backingStoreBitmap contains the flash drawing.
> > (even when the flash window is hidden)
> >
> > I think a better solution would be to use WM_PAINT hijacking in
> > PluginViewWin.cpp and insert your own HDC. ( note that in windowed
> > mode, all drawing is done by the plugin app through
> > PluginView::wndProc). I'm going to trail a solution this week which
> > does this. It should also support other plugins (reader, quicktime
> > etc). I'll likely post my findings to the group.
> >
> > Chris
> >
> >
> >
> > On Thu, Jul 22, 2010 at 9:26 AM, vizshala <vizshala at gmail.com> wrote:
> > > hi Chris,
> > >
> > > In your original post, you mentioned that it may be possible to let
> flash
> > > paint directly into the m_backingStoreBitmap or the dc we created. Did
> > you
> > > use api hijacking like the webkit did in pluginview or something else?
> > >
> > > thx
> > >
> > > 2010/7/13 Chris Hatko <chatko at gmail.com>
> > >>
> > >> Thanks Alex,
> > >>
> > >> I tried using paintDocumentRectToContext, but I was asking for the
> > >> paint 30/sec and found that providing a rectangle for the entire
> > >> window was too slow. I've made some progress with my original method
> > >> which only invalidates the flash/plugin areas and uses the
> > >> backingstore bitmap as the 30/sec snapshot. Below is some code I found
> > >> to search for plugin areas. I Hope it helps someone ...
> > >>
> > >> // get the plugin (flash) areas and invalidate them
> > >> IntRect pluginArea;
> > >>
> > >> for (Frame* frame = (this->m_page)->mainFrame(); frame; frame =
> > >> frame->tree()->traverseNext())
> > >> {
> > >> FrameView* view = frame->view();
> > >> if (!view)
> > >> return 0;
> > >>
> > >> const HashSet<RefPtr<Widget> >* children =
> > view->children();
> > >> ASSERT(children);
> > >>
> > >> HashSet<RefPtr<Widget> >::const_iterator end =
> > >> children->end();
> > >> for (HashSet<RefPtr<Widget> >::const_iterator it =
> > >> children->begin(); it != end; ++it)
> > >> {
> > >> Widget* widget = (*it).get();
> > >> if (widget->isPluginView()) // works for flash at
> > least
> > >> {
> > >> pluginArea =
> > >> (static_cast<PluginView*>(widget))->windowClipRect();
> > >> this->addToDirtyRegion(pluginArea);
> > >> }
> > >> }
> > >> }
> > >>
> > >>
> > >> One item i have noticed and that I've wasted many hours debugging is
> > >> that the latest Flash (10.1) doesn't render at full speed when it is
> > >> in a hidden window. I'll send another question to the group detailing
> > >> this.
> > >>
> > >> Thanks,
> > >>
> > >> Chris
> > >>
> > >>
> > >> On Mon, Jul 12, 2010 at 8:34 AM, Alexander Shulgin
> > >> <alexander.shulgin at yessoftware.com> wrote:
> > >> > On 09.07.2010 22:18, Chris Hatko wrote:
> > >> >>
> > >> >> Hi,
> > >> >>
> > >> >> My goal is to get the cario webkit port to render to a buffer
> instead
> > >> >> of a window (i'll be making the window invisible), with as little
> > >> >> change to the port source as possible.
> > >> >
> > >> > I'm using IWebFramePrivate::paintDocumentRectToContext(RECT, HDC)
> for
> > >> > this.
> > >> > It works with pretty reasonable results and w/o the need to modify
> > the
> > >> > source code.
> > >> >
> > >> > --
> > >> > Alex
> > >> > _______________________________________________
> > >> > webkit-help mailing list
> > >> > webkit-help at lists.webkit.org
> > >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
> > >> >
> > >> _______________________________________________
> > >> webkit-help mailing list
> > >> webkit-help at lists.webkit.org
> > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
> > >
> > >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-help/attachments/20100803/3c2f561e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Mon, 2 Aug 2010 21:58:15 -0700
> From: Dan Wood <dw43031apple at karelia.com>
> To: webkit-help at lists.webkit.org
> Subject: [webkit-help] Still completely stuck with getting
> JavaScriptCore to load this code
> Message-ID: <FA8B65B5-0661-43B1-8342-27EA70A566E2 at karelia.com>
> Content-Type: text/plain; charset=windows-1252
>
> I've posted here occasionally trying to figure out why I'm having such an
> issue loading a javascript library <http://github.com/cloudhead/less.js>,
> some code which is wrapped in an anonymous self-executing block. I *think*
> I'm feeding it everything it needs, but I'm just getting an undefined
> result.
>
> There seems to be almost no documentation for JavaScriptCore that I can
> find, and without a debugger, I feel like I'm shining a flashlight
> underwater to try and figure out what is going on.
>
>
> Out of desperation, I've put my source code up -- it's really only about
> 30 lines for the main functionality -- to see if anybody else can figure out
> why I'm completely not having any luck here.
>
> Is there anybody who is familiar with JavaScriptCore who could look at this
> project, and maybe give me some hints as to why I'm not successful in
> loading the JavaScript code?
>
> http://dl.dropbox.com/u/1284131/LessInterpreter.zip
>
> (Ignore the UI -- just step through -[MyController init] ....)
>
> >From what I can tell, the code is intended to be runnable as a standalone
> if you have an undefined window object; it is supposed to add some
> properties to 'exports' according to the developer of the code. <
> http://github.com/cloudhead/less.js/issues/issue/62/>
>
> I haven't gotten much further in jsc. I've tried something like this:
>
> > exports = {}
> > load ('less.js')
>
> but it's complaining about window not being defined, which seems weird
> since the code is supposed to test if window is undefined.
>
> I thought I'd do a 'checkSyntax" but that is yielding a segmentation fault.
>
>
> Any hints would be really helpful.
>
>
> Thanks,
> Dan
>
>
>
> --
> Dan Wood
> dwood at karelia.com
> Twitter: http://twitter.com/danwood
> Karelia Software ? Sandvox for the Mac
> http://www.karelia.com/
>
> He who passively accepts evil is as much involved in it as he who helps to
> perpetrate it. He who accepts evil without protesting against it is really
> cooperating with it. ? Martin Luther King, Jr.
>
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> webkit-help mailing list
> webkit-help at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
>
>
> End of webkit-help Digest, Vol 14, Issue 3
> ******************************************
>
--
Be to GOD as he wants ,
HE'll be for you more
than what you want.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-help/attachments/20100803/145ad156/attachment-0001.html>
More information about the webkit-help
mailing list