- Pharo-users - lists.pharo.org

Re: [Pharo-users] ZnWebSocket and Seaside ZnZincServerAdaptor

by Norbert Hartl

Am 13.03.2013 um 03:15 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > Hi, > > Is there a way to use the same server Seaside is using to plug a > ZnWebSocketDelegate into it? > > The ZnZincServerAdaptor runs by default as the root delegator for its server > (at whatever port it was started), but I was wondering if there is a way to > reuse the same server Seaside (on top of Zinc) is using, to plug different > WS handlers. > > By now I'm just using another server to run the WS, which is no big deal > except to open an extra port in my server. I had the same problem. I wanted to deliver an image without frontend server so the extra ports can be somewhat awkward. I didn't adopt the newest changes from Sven, yet. I do it this way startServer | staticFileDelegate seasideAdaptor | seasideAdaptor := ZnZincServerAdaptor port: self port. WAServerManager default adaptors do: [:each| WAServerManager default unregister: each ]. staticFileDelegate := NTedStaticFileServerDelegate new directory: ( FileDirectory default containingDirectory directoryNamed: 'web'). (ZnServer startDefaultOn: self port) debugMode: true; delegate: ( NTedContextDispatcherDelegate new map: 'ws' to: (ZnWebSocketDelegate map: 'ws' to: NTedWebSocketHandler new); map: 'css' to: staticFileDelegate; map: 'js' to: staticFileDelegate; map: 'img' to: staticFileDelegate; map: 'font' to: staticFileDelegate; map: 'csv' to: NTedCSVHandler new; map: 'admin' to: ( NTedContextDispatcherDelegate new map: 'css' to: staticFileDelegate; map: 'js' to: staticFileDelegate; map: 'img' to: staticFileDelegate; map: 'font' to: staticFileDelegate; defaultHandler: (ZnSeasideServerAdaptorDelegate with: seasideAdaptor) ); defaultHandler: staticFileDelegate ). This way I start a one click image server that contains its static resource within the one click distribution directory and serves WebSockets, a little CSV http handler and seaside for the admin interface. All on the same port and ready when the image is opened. NTedStaticFileServerDelegate is basically a ZnStaticFileServerDelegate that adds some cache headers for resources. NTedContextDispatcherDelegate maps context paths to handlers. It uses a path consumer so that you can use more levels of configuration like in the above example. That means every level takes away the first part of the url. Hope that helps, Norbert

March 13, 2013

Re: [Pharo-users] Nautilus class references?

by jannik laval

ahah, I hope that it will be disabled by default for the release. I understand the power you say. But for now, it is only available in a part of Nautilus. So switching between two different keybindings in the same environment is not efficient. Cheers, Jannik 2013/3/13 Esteban Lorenzano <estebanlm(a)gmail.com> > with the new commands: cmd+b+N > you also can choose the old keybiindings (in settings), but you will lose > all the power of the new ones :) > > Esteban > > > On Mar 13, 2013, at 11:36 AM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > > > Hi list, > > > > How does one get the references to a class in Nautilus? In RB it used to > be control+N, now I can't find it anywhere, not even in the context menus... > > > > Thanks! > > > > Bernat. > > > > -- > > Bernat Romagosa. > > > -- ~~Dr. Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu

March 13, 2013

Re: [Pharo-users] Nautilus class references?

by Sven Van Caekenberghe

On 13 Mar 2013, at 11:36, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > How does one get the references to a class in Nautilus? In RB it used to be control+N, now I can't find it anywhere, not even in the context menusâ¦ The menu item is (on the class) Analyze > Class refsâ¦ Sven

March 13, 2013

Re: [Pharo-users] Nautilus class references?

by Bernat Romagosa

Ok, I see! Thanks Esteban! Is there a place where one can find a comprehensive list of all the shortcuts? I'm going a bit insane... T_T 2013/3/13 Esteban Lorenzano <estebanlm(a)gmail.com> > with the new commands: cmd+b+N > you also can choose the old keybiindings (in settings), but you will lose > all the power of the new ones :) > > Esteban > > > On Mar 13, 2013, at 11:36 AM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > > > Hi list, > > > > How does one get the references to a class in Nautilus? In RB it used to > be control+N, now I can't find it anywhere, not even in the context menus... > > > > Thanks! > > > > Bernat. > > > > -- > > Bernat Romagosa. > > > -- Bernat Romagosa.

March 13, 2013

Re: [Pharo-users] Nautilus class references?

by Esteban Lorenzano

with the new commands: cmd+b+N you also can choose the old keybiindings (in settings), but you will lose all the power of the new ones :) Esteban On Mar 13, 2013, at 11:36 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hi list, > > How does one get the references to a class in Nautilus? In RB it used to be control+N, now I can't find it anywhere, not even in the context menus... > > Thanks! > > Bernat. > > -- > Bernat Romagosa.

March 13, 2013

Nautilus class references?

by Bernat Romagosa

Hi list, How does one get the references to a class in Nautilus? In RB it used to be control+N, now I can't find it anywhere, not even in the context menus... Thanks! Bernat. -- Bernat Romagosa.

March 13, 2013

Re: [Pharo-users] ZnWebSocket and Seaside ZnZincServerAdaptor

by Sven Van Caekenberghe

Hi Esteban, On 13 Mar 2013, at 03:15, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi, > > Is there a way to use the same server Seaside is using to plug a > ZnWebSocketDelegate into it? > > The ZnZincServerAdaptor runs by default as the root delegator for its server > (at whatever port it was started), but I was wondering if there is a way to > reuse the same server Seaside (on top of Zinc) is using, to plug different > WS handlers. > > By now I'm just using another server to run the WS, which is no big deal > except to open an extra port in my server. > > Regards! I have several images that run multiple servers concurrently, especially separating the web socket stuff in a second server sounds like a good idea to me. By fiddling with different mappings in the default handler you can actually set up quite complex systems (like routes in other systems). But of course, there can only be one / handler. Regarding the Zinc Seaside Adaptor, some recent changes make it possible to run Seaside under /seaside instead of under /. ZnSeasideServerAdaptorDelegate>>installInServer: znServer underPrefix: prefix "Install a ZnSeasideServerAdaptorDelegate in znServer under prefix, provided znServer contains a ZnDefaultServerDelegate instance as primary delegate. Note that the incoming request is destructively modified." | seasideDelegate | seasideDelegate := self forServer: znServer. znServer delegate map: 'seaside' to: [ :request | request uri segments: request uri segments allButFirst. seasideDelegate handleRequest: request ]. ^ seasideDelegate Now execute the following line WAAdmin defaultDispatcher serverPath: prefix. And Seaside now works mostly as usual, including links and static files. There seem to be some links that don't work, but I guess that are actually bugs. Mind you, this is all a bit bleeding edge ;-) This might be interesting as well: http://forum.world.st/Running-ZnZincServerAdaptor-outside-WAServerManager-t… Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 13, 2013

Re: [Pharo-users] RFBServer>>#encryptPassword: wipes the password thats passed in and I'm confused why that's ok.

by Paul DeBruicker

On 03/12/2013 11:50 PM, Paul DeBruicker wrote: > IF I load the RFB package from lukas's site[1] (Pharo 1.4, recent enough > VM, linux) and set the RFB server's fullPassword like this: > > MyObject>>startRFB > RFBServer current setFullPassword: self rfbPassword > > MyObject>>rfbPassword > ^'1234' > > > After that send the source of rfbPassword shows '1234' but the bytecodes > show that it is '' and the apparently empty string is 8 bytes long with > each character being (Character value:0) > > > #setFullPassword: uses #atAllPut: to set the value of #rfbPassword to > 'Character value: 0'. > > My concerns are these: > > 1. Using the current implementation its impossible to stop and restart > the RFB server with a default password programmatically. > > 2. The implementation is not idempotent when starting/stopping. > > 3. I don't understand the security consequences of removing the part > where the password sent to #encryptPassword: is set to NULL characters. > > Is wiping the values of the #rfbPassword method necessary for security > reasons? I assume that setting the RFB server to only accept > connections from localhost and using X forwarding would take care of > most of the risk of having a string literal in the image. > > > Or- should I be accessing a default RFB password from another source > than a class side method in the image? > > Is there a standard practice for starting and stopping the RFB server in > Pharo 1.4 where the RFB server is up and down during the time the image > is up? > > > Thanks for any advice > > > Paul > > > > > 1 - The change was from this package: RFB-MiguelCoba.26.mcz from this > repo: http://source.lukas-renggli.ch/unsorted > Oh and if you want to see what I'm talking about load the latest from Lukas's site and run this RFBServer current inspect. pwd:='nintendo'. correctHash :=#[223 3 196 119 26 39 155 190]. 3 timesRepeat: [RFBServer current initializePreferences; configureForMemoryConservation; allowEmptyPasswords: false; allowRemoteConnections: false; yourself. RFBServer current setFullPassword: pwd. RFBServer current start: 1. RFBServer stop]. Then in the inspector check the value of the vncPassword inst var. The first value of the array should be #[223 3 196 119 26 39 155 190] if it were idempotent but is #[90 178 205 192 186 220 175 19] which is the hash value for an 8 byte NULL character password.

March 13, 2013

RFBServer>>#encryptPassword: wipes the password thats passed in and I'm confused why that's ok.

by Paul DeBruicker

IF I load the RFB package from lukas's site[1] (Pharo 1.4, recent enough VM, linux) and set the RFB server's fullPassword like this: MyObject>>startRFB RFBServer current setFullPassword: self rfbPassword MyObject>>rfbPassword ^'1234' After that send the source of rfbPassword shows '1234' but the bytecodes show that it is '' and the apparently empty string is 8 bytes long with each character being (Character value:0) #setFullPassword: uses #atAllPut: to set the value of #rfbPassword to 'Character value: 0'. My concerns are these: 1. Using the current implementation its impossible to stop and restart the RFB server with a default password programmatically. 2. The implementation is not idempotent when starting/stopping. 3. I don't understand the security consequences of removing the part where the password sent to #encryptPassword: is set to NULL characters. Is wiping the values of the #rfbPassword method necessary for security reasons? I assume that setting the RFB server to only accept connections from localhost and using X forwarding would take care of most of the risk of having a string literal in the image. Or- should I be accessing a default RFB password from another source than a class side method in the image? Is there a standard practice for starting and stopping the RFB server in Pharo 1.4 where the RFB server is up and down during the time the image is up? Thanks for any advice Paul 1 - The change was from this package: RFB-MiguelCoba.26.mcz from this repo: http://source.lukas-renggli.ch/unsorted

March 13, 2013

ZnWebSocket and Seaside ZnZincServerAdaptor

by Esteban A. Maringolo

Hi, Is there a way to use the same server Seaside is using to plug a ZnWebSocketDelegate into it? The ZnZincServerAdaptor runs by default as the root delegator for its server (at whatever port it was started), but I was wondering if there is a way to reuse the same server Seaside (on top of Zinc) is using, to plug different WS handlers. By now I'm just using another server to run the WS, which is no big deal except to open an extra port in my server. Regards! -- View this message in context: http://forum.world.st/ZnWebSocket-and-Seaside-ZnZincServerAdaptor-tp4676528… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 13, 2013