This is the kind of thing that seaside needs to have to attract more people.
Lawson
2012/1/23 Lawson English lenglish5@cox.net:
This is the kind of thing that seaside needs to have to attract more people.
We though about this several times and it's really hard to do without giving people complete control over the image which in turn will give them user rights on the server.
Cheers Philippe
What about Amber? And then just limit the classes that are ever shown to the user and delete them after the session times out or whatever?
RS
Date: Mon, 23 Jan 2012 19:25:08 +0100 Subject: Re: [Seaside] Live Ruby on rails tutorial sites From: philippe.marschall@gmail.com To: lenglish5@cox.net; seaside@lists.squeakfoundation.org
2012/1/23 Lawson English lenglish5@cox.net:
This is the kind of thing that seaside needs to have to attract more people.
We though about this several times and it's really hard to do without giving people complete control over the image which in turn will give them user rights on the server.
Cheers Philippe _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
2012/1/23 Robert Sirois watchlala@hotmail.com:
What about Amber?
Amber doesn't run Seaside.
And then just limit the classes that are ever shown to the user and delete them after the session times out or whatever?
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
Cheers Philippe
Aw too bad then. I think some of the book resources out there are good enough. I remember when I was learning that I just didn't understand the scope of everything, and there wasn't a nicely illustrated graph of the api or anything. Of course, I picked seaside and smalltalk with very little programming experience to learn at the same time hehe.
RS
Date: Mon, 23 Jan 2012 21:05:07 +0100 Subject: Re: [Seaside] Live Ruby on rails tutorial sites From: philippe.marschall@gmail.com To: seaside@lists.squeakfoundation.org
2012/1/23 Robert Sirois watchlala@hotmail.com:
What about Amber?
Amber doesn't run Seaside.
And then just limit the classes that are ever shown to the user and delete them after the session times out or whatever?
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
Cheers Philippe _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Hi all!
On 01/23/2012 09:05 PM, Philippe Marschall wrote:
2012/1/23 Robert Siroiswatchlala@hotmail.com:
What about Amber?
Amber doesn't run Seaside.
True, but Amber does have a similar Canvas API and Widget is similar to WAComponent in its role etc. So yes, definitely *not* the same thing - but if the goal is to attract people to the "Smalltalk arena" of web apps it is still a good thing to have.
And with Amber there is no problem letting the users go berzerk - it's all on the client side anyway, and one can use local storage etc to make sure stuff is not "lost".
But again - not Seaside. But similar. ;)
regards, Göran
PS. I love Seaside and Iliad etc, but for me personally it's all about client side now. We are using javascript with the help from Nicolas to build a full "fat" HTML5 client for a customer. And for a personal project I am going "all Amber" for the client. The server then gets transformed into a "RPC backend". And for that, one can use a multitude of technology, with Socket.io being the "sexiest".
makes sense.
Question Goran: what would be the preferred persistent method in such apps?
sebastian
o/
On Jan 24, 2012, at 6:38 AM, Göran Krampe wrote:
Hi all!
On 01/23/2012 09:05 PM, Philippe Marschall wrote:
2012/1/23 Robert Siroiswatchlala@hotmail.com:
What about Amber?
Amber doesn't run Seaside.
True, but Amber does have a similar Canvas API and Widget is similar to WAComponent in its role etc. So yes, definitely *not* the same thing - but if the goal is to attract people to the "Smalltalk arena" of web apps it is still a good thing to have.
And with Amber there is no problem letting the users go berzerk - it's all on the client side anyway, and one can use local storage etc to make sure stuff is not "lost".
But again - not Seaside. But similar. ;)
regards, Göran
PS. I love Seaside and Iliad etc, but for me personally it's all about client side now. We are using javascript with the help from Nicolas to build a full "fat" HTML5 client for a customer. And for a personal project I am going "all Amber" for the client. The server then gets transformed into a "RPC backend". And for that, one can use a multitude of technology, with Socket.io being the "sexiest". _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On 01/24/2012 12:36 PM, Sebastian Sastre wrote:
makes sense.
Question Goran: what would be the preferred persistent method in such apps?
sebastian http://about.me/sebastianconcept
Well, let me go "off topic" all the way, IMHO the "dream" stack for me personally (for a fairly advanced system) looks something like this:
1. Amber (or plain js) on client side + socket.io (optionally + Faye or Juggernaut). I am getting more proficient in js these days, but Amber is still much nicer. Building an advanced client in js requires a lot of ... care. :)
2. Server side a mixture of: - Amber running on nodejs. - Plain js on nodejs. - Pharo. The system I am building has different "tasks" that are sometimes better done in Pharo and sometimes better done in nodejs (js or Amber) since there are a LOT of pre made node modules to use.
3. Tying them together using a message queue. For the moment I think the new ActiveMQ called "Apollo" looks best. It has VERY good performance and is all focused on the STOMP protocol (for which I have already written a client library for Squeak). Yes, written in Java, but I just want to use it :)
4. Persistence... I am in love with Riak and that is where I am placing my effort right now. Membase would also be fun to play with, as would Redis, but Redis is not a persistence solution but rather a coordination mechanism giving atomic behaviors in a NoSQL-transaction-less-world.
regards, Göran
2012/1/24 Göran Krampe goran@krampe.se:
Hi all!
On 01/23/2012 09:05 PM, Philippe Marschall wrote:
2012/1/23 Robert Siroiswatchlala@hotmail.com:
What about Amber?
Amber doesn't run Seaside.
True, but Amber does have a similar Canvas API and Widget is similar to WAComponent in its role etc. So yes, definitely *not* the same thing - but if the goal is to attract people to the "Smalltalk arena" of web apps it is still a good thing to have.
And with Amber there is no problem letting the users go berzerk - it's all on the client side anyway, and one can use local storage etc to make sure stuff is not "lost".
Sure, then we're talking about running Amber in the browser with is totally fine and doesn't have any of the issues as giving a random user control over a Smalltalk image on the server.
But again - not Seaside. But similar. ;)
regards, Göran
PS. I love Seaside and Iliad etc, but for me personally it's all about client side now. We are using javascript with the help from Nicolas to build a full "fat" HTML5 client for a customer. And for a personal project I am going "all Amber" for the client. The server then gets transformed into a "RPC backend". And for that, one can use a multitude of technology, with Socket.io being the "sexiest".
Since you're taking this off topic I hope you don't mind if I ask some questions. What sever do you use? Which "protocol" do you use (WebSocket, long poll, …)?
Cheers Philippe
I'd love to use Amber on the client and Seaside + the JSON package on the server. I have some extensions added to Kaliningrad and so far it seems to work fine. Seaside-JSON components are used to send both data and callback ids to the client (Amber).
Cheers, Nico
On Tue, 2012-01-24 at 14:31 +0100, Philippe Marschall wrote:
PS. I love Seaside and Iliad etc, but for me personally it's all about client side now. We are using javascript with the help from Nicolas to build a full "fat" HTML5 client for a customer. And for a personal project I am going "all Amber" for the client. The server then gets transformed into a "RPC backend". And for that, one can use a multitude of technology, with Socket.io being the "sexiest".
Since you're taking this off topic I hope you don't mind if I ask some questions. What sever do you use? Which "protocol" do you use (WebSocket, long poll, …)?
Cheers Philippe _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
2012/1/24 Nicolas Petton petton.nicolas@gmail.com:
I'd love to use Amber on the client and Seaside + the JSON package on the server. I have some extensions added to Kaliningrad and so far it seems to work fine. Seaside-JSON components are used to send both data and callback ids to the client (Amber).
You're using Seaside-JSON [1]? Cool! Right now JSON callbacks are only niladic. Let me know when that becomes an issue for you and we'll think of something.
[1] http://www.squeaksource.com/Seaside31Addons.html
Cheers Philippe
On Tue, 2012-01-24 at 20:24 +0100, Philippe Marschall wrote:
2012/1/24 Nicolas Petton petton.nicolas@gmail.com:
I'd love to use Amber on the client and Seaside + the JSON package on the server. I have some extensions added to Kaliningrad and so far it seems to work fine. Seaside-JSON components are used to send both data and callback ids to the client (Amber).
You're using Seaside-JSON [1]? Cool!
Yep :)
Right now JSON callbacks are only niladic. Let me know when that becomes an issue for you and we'll think of something.
Yeah, I subclassed the JSON canvas just for that. What It does is send a JSON string in a POST request and evaluate a WAValueCallback with the parsed JSON.
This means that it expects some JSON data, but this workaround works fine for now.
Cheers, Nico
[1] http://www.squeaksource.com/Seaside31Addons.html
Cheers Philippe _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
2012/1/24 Nicolas Petton petton.nicolas@gmail.com:
On Tue, 2012-01-24 at 20:24 +0100, Philippe Marschall wrote:
2012/1/24 Nicolas Petton petton.nicolas@gmail.com:
I'd love to use Amber on the client and Seaside + the JSON package on the server. I have some extensions added to Kaliningrad and so far it seems to work fine. Seaside-JSON components are used to send both data and callback ids to the client (Amber).
You're using Seaside-JSON [1]? Cool!
Yep :)
Right now JSON callbacks are only niladic. Let me know when that becomes an issue for you and we'll think of something.
Yeah, I subclassed the JSON canvas just for that. What It does is send a JSON string in a POST request and evaluate a WAValueCallback with the parsed JSON.
Good ideas, that's simpler than what I had in mind.
Cheers Philippe
Hi!
On 01/24/2012 02:31 PM, Philippe Marschall wrote:
2012/1/24 Göran Krampegoran@krampe.se:
PS. I love Seaside and Iliad etc, but for me personally it's all about client side now. We are using javascript with the help from Nicolas to build a full "fat" HTML5 client for a customer. And for a personal project I am going "all Amber" for the client. The server then gets transformed into a "RPC backend". And for that, one can use a multitude of technology, with Socket.io being the "sexiest".
Since you're taking this off topic I hope you don't mind if I ask some questions. What sever do you use? Which "protocol" do you use (WebSocket, long poll, …)?
For the customer we just use jQuery Ajax calls - we have a .Net server at the backend.
For my personal project I intend to try Socket.io possibly with Juggernaut in the mix:
http://socket.io https://github.com/maccman/juggernaut
An alternative would be:
This would lead to a server running in nodejs so I can write it either in Amber or plain js. Since I want the main part of the system written in Pharo I am pursuing using a message queue to tie it all together and keeping the parts running in nodejs to be as small and targeted as possible.
regards, Göran
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
you could always use chroot [1] and isolate each web app user's environment.
2012/1/24 Nick Ager nick.ager@gmail.com:
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
you could always use chroot [1] and isolate each web app user's environment.
Right then you just need to add an additional proxy that forwards to each users image and shuts down the image when the session times out. It also has to start images on a free port. At this point you're more or less building seasidehosting.st.
There are just so many unsolved problems I don't even know where to start. Writing a mail saying "you could just" or "or whatever" doesn't solve them. If somebody wants to go ahead and build something like this, by all means go head.
Cheers Philippe
On Tue, Jan 24, 2012 at 2:42 PM, Nick Ager nick.ager@gmail.com wrote:
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
you could always use chroot [1] and isolate each web app user's environment.
On SmallHarbour we use a secured VM so each image run in a "jail" and cannot access filesystem out of its root dir. There's some (ugly / hacky) automated image deployment. If someone want to play with I can help.
Laurent
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Laurent, just for curiosity, in FreeBSD I know that existing Jails, do you use FreeBSD jails? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
2012/1/25 laurent laffont laurent.laffont@gmail.com
On Tue, Jan 24, 2012 at 2:42 PM, Nick Ager nick.ager@gmail.com wrote:
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
you could always use chroot [1] and isolate each web app user's environment.
On SmallHarbour we use a secured VM so each image run in a "jail" and cannot access filesystem out of its root dir. There's some (ugly / hacky) automated image deployment. If someone want to play with I can help.
Laurent
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
2012/1/28 Gastón Dall' Oglio gaston.dalloglio@gmail.com
Laurent, just for curiosity, in FreeBSD I know that existing Jails, do you use FreeBSD jails? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
No. I have not booted a FreeBSD for years .....
Laurent
2012/1/25 laurent laffont laurent.laffont@gmail.com
On Tue, Jan 24, 2012 at 2:42 PM, Nick Ager nick.ager@gmail.com wrote:
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
you could always use chroot [1] and isolate each web app user's environment.
On SmallHarbour we use a secured VM so each image run in a "jail" and cannot access filesystem out of its root dir. There's some (ugly / hacky) automated image deployment. If someone want to play with I can help.
Laurent
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Ah ok, I never :) But I have curiosity for this tecnology of jails in FreeBSD for hosted seaside instances. Regards.
2012/1/28 laurent laffont laurent.laffont@gmail.com
2012/1/28 Gastón Dall' Oglio gaston.dalloglio@gmail.com
Laurent, just for curiosity, in FreeBSD I know that existing Jails, do you use FreeBSD jails? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
No. I have not booted a FreeBSD for years .....
Laurent
2012/1/25 laurent laffont laurent.laffont@gmail.com
On Tue, Jan 24, 2012 at 2:42 PM, Nick Ager nick.ager@gmail.com wrote:
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
you could always use chroot [1] and isolate each web app user's environment.
On SmallHarbour we use a secured VM so each image run in a "jail" and cannot access filesystem out of its root dir. There's some (ugly / hacky) automated image deployment. If someone want to play with I can help.
Laurent
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
You need to define what you are willing to risk. Then you need to define your sandbox. Chroot and jail are similar and basically isolate just on the filesystem layer. Access to other resources is not easy possible because inside the jail there is no default access. But you give away control over the jailed environment. A malicious person can still bring his own binaries and abuse the network. If you are looking for better isolation and you are not to eager to use freeBSD then have a look at linux containers LXC [1]. Anyway you give away access to resources like the network. If you need better isolation then you would need to get rid of the primitives in the vm. Probably it is not to hard to get rid of system accessing primitives after the image has been loaded and changes etc. are disabled. I think Igor proposed something with an irreversible primitive call that disables some primitives.
my 2 cents,
Norbert
[1] http://lxc.sourceforge.net/
Am 31.01.2012 um 13:36 schrieb Gastón Dall' Oglio:
Ah ok, I never :) But I have curiosity for this tecnology of jails in FreeBSD for hosted seaside instances. Regards.
2012/1/28 laurent laffont laurent.laffont@gmail.com 2012/1/28 Gastón Dall' Oglio gaston.dalloglio@gmail.com Laurent, just for curiosity, in FreeBSD I know that existing Jails, do you use FreeBSD jails? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
No. I have not booted a FreeBSD for years .....
Laurent
2012/1/25 laurent laffont laurent.laffont@gmail.com On Tue, Jan 24, 2012 at 2:42 PM, Nick Ager nick.ager@gmail.com wrote: Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
you could always use chroot [1] and isolate each web app user's environment.
[1] http://en.wikipedia.org/wiki/Chroot
On SmallHarbour we use a secured VM so each image run in a "jail" and cannot access filesystem out of its root dir. There's some (ugly / hacky) automated image deployment. If someone want to play with I can help.
Laurent
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Hi Norbert.
You need to define what you are willing to risk.
Chroot and jail are similar and basically isolate just on the filesystem
layer.
2012/1/31 Norbert Hartl norbert@hartl.name
You need to define what you are willing to risk.
Yes right, I just have interesting about jails, but just now I do not have a real scenario, I'm the only user in my hosting.
Then you need to define your sandbox. Chroot and jail are similar and basically isolate just on the filesystem layer. Access to other resources is not easy possible because inside the jail there is no default access. But you give away control over the jailed environment. A malicious person can still bring his own binaries and abuse the network.
As far I know, jail are more like a OS virtual machine, becouse it be able to control other resource not only file system, like your proccess and network configurations, see See: http://en.wikipedia.org/wiki/FreeBSD_jail. But not controled the cpu and ram utilization, and then yes a user can be abusing of them and network. But for control the network usage i think that the best approach is a firewall external to the jails (and good switch :).
If you are looking for better isolation and you are not to eager to use freeBSD then have a look at linux containers LXC [1]. Anyway you give away access to resources like the network.
Thanks for the data, I check lxc that mu hosting is a Linux box.
If you need better isolation then you would need to get rid of the
primitives in the vm. Probably it is not to hard to get rid of system accessing primitives after the image has been loaded and changes etc. are disabled. I think Igor proposed something with an irreversible primitive call that disables some primitives.
Very advance for my, but sounds like the better solution.
my 2 cents,
Norbert
Thanks. Gastón.
[1] http://lxc.sourceforge.net/
Am 31.01.2012 um 13:36 schrieb Gastón Dall' Oglio:
Ah ok, I never :) But I have curiosity for this tecnology of jails in FreeBSD for hosted seaside instances. Regards.
2012/1/28 laurent laffont laurent.laffont@gmail.com
2012/1/28 Gastón Dall' Oglio gaston.dalloglio@gmail.com
Laurent, just for curiosity, in FreeBSD I know that existing Jails, do you use FreeBSD jails? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
No. I have not booted a FreeBSD for years .....
Laurent
2012/1/25 laurent laffont laurent.laffont@gmail.com
On Tue, Jan 24, 2012 at 2:42 PM, Nick Ager nick.ager@gmail.com wrote:
Ce n'est pas si facile que ça.
(1 perform: ('cla', 'ss') asSymbol) environment at: ('Comp', 'iler') asSymbol
And again, you give the web app user the full rights of the OS user that runs the image. Deleting the code that owned you after the session times out doesn't solve a thing once you've been owned. It also doesn't help if two users at the same time want to work on a class named 'Test' or 'MyClass' or 'Example'.
you could always use chroot [1] and isolate each web app user's environment.
On SmallHarbour we use a secured VM so each image run in a "jail" and cannot access filesystem out of its root dir. There's some (ugly / hacky) automated image deployment. If someone want to play with I can help.
Laurent
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Or DabbleDB style hehe. Worlds biggest backend for a tutorial website lol.
RS
Date: Mon, 23 Jan 2012 19:25:08 +0100 Subject: Re: [Seaside] Live Ruby on rails tutorial sites From: philippe.marschall@gmail.com To: lenglish5@cox.net; seaside@lists.squeakfoundation.org
2012/1/23 Lawson English lenglish5@cox.net:
This is the kind of thing that seaside needs to have to attract more people.
We though about this several times and it's really hard to do without giving people complete control over the image which in turn will give them user rights on the server.
Cheers Philippe _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
If I remember well, Bernat showed something like this at ESUG 2011. Don't know how they solve the security problems (if solved)...
On 23/01/12 09:12, Lawson English wrote:
This is the kind of thing that seaside needs to have to attract more people.
Lawson
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside@lists.squeakfoundation.org
-
Francois Stephany -
Gastón Dall' Oglio -
Göran Krampe -
laurent laffont -
Lawson English -
Nick Ager -
Nicolas Petton -
Norbert Hartl -
Philippe Marschall -
Robert Sirois -
Sebastian Sastre