Re: Appending Sessionid to all the urls
Stuart Frew <[EMAIL PROTECTED]> writes: > The user is using the system to process client A. The cookie contains > stateful information including the client ID. > > They then open an new browser window, and lookup client B, recieving a > new session ID with new state information, including the client ID. > > The user then submits the form to the server. > > The server then recives the one and only cookie with a session ID in it. > But is it for Client A or Client B? 50-50 chance of updating the right > row. Not good. Session information should be used for the most minimal set of data possible. Often times sessions get used where pnotes would be better, or where hidden form variables would be better. The situation you describe is unlikely and avoidable if you set out with the idea in mind to not put anything in a session that absolutely doesn't need to be there; use your database to store information if you need to and if at all feasible. The problem you mention is real, but in "real world scenarios" it can typically be avoided. About the only thing you can't avoid is if the user wants to log in simultaneously as two different users. Most normal users don't want to do that, though :) Chip -- Chip Turner [EMAIL PROTECTED] RHN Web Engineer
Re: Real Widgets and Template Languages
Gunther Birznieks <[EMAIL PROTECTED]> writes:
> However, I think it is reasonable to make the interface to support a
> data source for the widgets flexible and object based to make it easy
> for someone to write a DBI source, a DBM source, an LDAP source, an
> Apache::Session source or whatever anyone wants really. I happen to
> think DBI and Session sources are cool.
I agree; unfortunately writing classes to interface to all of these
would be difficult, and it would be difficult to be futureproof. When
you hit LDAP and DBI you must then worry about databases, tables,
servers, usernames, passwords, etc. It can become cumbersome to do
the simple things.
> By default, it could be GPC chaining like PHP (Get, Post,
> Cookie) But with enough widget data sources to choose from you
> could do
>
> GPCSD (Get, Post, Cookie, Session, Database) type of thing.
This can be done quite well from a closure:
my $dbh = DBI->connect(...);
my $sth = $dbh->prepare('SELECT foo FROM persistant_data WHERE id = ?');
my $cgi = new CGI;
my $data_closre =
sub {
my $key = shift;
my $return = $cgi->param($key);
$return = $cgi->cookie($key)
unless defined $return;
if (not defined $return) {
$sth->execute($key);
($return) = $sth->fetchrow;
$sth->finish;
}
return $return;
};
Now the closre, though slightly more complicated, doesn't need to know
anything about the world around it, and neatly cinches off the
interface from Widget into DBI, CGI, cookies, etc etc. Using classes
for this would work, but it could be cumbersome; a closure allows for
near infinite flexibility... but at the price of complexity.
> I think but am not sure that closures likely also have better
> performance than method lookups. If this is the case, it could make
> sense to support a few data sources that need high performance because
> of their common use: CGI.pm and Apache::Request. Yet provide the
> extensibility for other developers to inject their own data sources
> into the chain using an Object-based API.
Closures are indeed faster than both instance method calls and package
method calls. However, this is a very basic thing; if performance is
critical enough to optimize this portion of a program then likely
someone wouldn't be using Widgets anyway :)
> Maybe someone else could comment on the technical merit of closure vs
> objects as well as the way in which they have been expecting the
> widgets to get populated? Is what I am saying make sense?
Below is a script to benchark the various invocations. The baseline
is for a function (method, closure, package method) to take one data
parameter and return something based on it.
The results I get on a dual P3 500 are:
[cturner@magneto cturner]$ perl bench.pl
Benchmark: timing 400 iterations of closure, method, pkgmethod...
closure: 10 wallclock secs ( 9.88 usr + 0.00 sys = 9.88 CPU) @ 404858.30/s
(n=400)
method: 22 wallclock secs (20.98 usr + 0.00 sys = 20.98 CPU) @ 190657.77/s
(n=400)
pkgmethod: 35 wallclock secs (35.59 usr + 0.00 sys = 35.59 CPU) @ 112391.12/s
(n=400)
bench.pl:
#!/usr/bin/perl -w
use strict;
use Benchmark;
my $meth = new Foo;
my $cref = sub { my $data = shift; return 1 };
timethese(400, { 'method' => sub { return $meth->bar },
'closure' => sub { return $cref->() },
'pkgmethod' => sub { return Foo->bar }});
package Foo;
sub new {
return bless {}, shift;
}
sub bar {
my $self = shift;
my $data = shift;
return 1;
}
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Real Widgets and Template Languages
Paul Lindner <[EMAIL PROTECTED]> writes:
> On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote:
> > darren chamberlain <[EMAIL PROTECTED]> writes:
> >
> > The nice thing about closures is they could hide any interface at all
> > behind them; all that is required is that the function that generates
> > the closure follow the very simple convention of "return the formvar
> > of the name starting with the first parameter you're called with."
> > There is absolutely no reliance upon the underlying object structure.
> > What you're suggesting is equivalent to assuming the object is derived
> > from some kind of base class that supports the param() method though
> > without actually having to be ISA of that class. That's naughty OO
> > programming :) Just because perl lets you be typeless doesn't mean
> > it's always in the best interest of clean design to do so.
>
> I don't find a problem with passing an object that has a certain set
> of method signatures. This is functionally loosely equivalent to a
> Java Interface.. Any perl object can implement a particular interface
> just by implementing the methods.. No base class required..
My only objection to this (as I stated in another email) is that it
leaves things largely unspecified. It's similar to the old perl
problem of passing big hashes around; you assume the data is there,
but there's no real way to find out without checking keys and so
forth. A simple $foo->isa('Widget::CGIData') can ensure that what
you're talking to is at least derived from the right thing. Just
because perl would let you call methods on a class not derived from a
standard base doesn't mean it's necessarily appropriate. An abstract
base class offers little overhead (especially if you override all of
the methods) while still giving that little bit of insurance about
just what you've been passed. In a library that conceivably could be
used by a number of people, such discipline would probably be a nice
thing, even if it didn't actually buy anything in terms of performance
or features.
> But I agree, closure are very cool, and allow for an additional layer
> of abstraction between the objects, without having to create a proxy
> class..
Closures are definitely cool. As someone else mentioned, requiring
-all- users of Widgets to use them probably limits the audience,
though, so some level of "smartness" in the Widget system would be
nice; perhaps autogenerating a closure for the things it knows about
(CGI.pm, libapreq, etc).
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Real Widgets and Template Languages
Gunther Birznieks <[EMAIL PROTECTED]> writes: > While I think that it is clever to allow an interface to change where > the parameters come from, I think in practice there are different > things to expect. eg how to deal with multi-values? How to deal with > file upload field? I think there are quirks in various libraries. Indeed, these are open questions that aren't dealt with so easily with a closure. But I think for a general widget set, a closure would work. If you want to get really tricky, you can bless the closure... but at that point, you should just be using a class in the first place. > I do not think these things are insurmountable. And Chip's suggestion > stands a good chance of working. I do also think there are so few > libraries to deal with parameters that it would not be an unreasonable > design decision to make the Widget controller hard code knowledge of > CGI.pm, Apache::Request and any others since there really aren't many. I disagree here; Mason, Apache::ASP, embperl, straight modperl, CGI.pm, the various CGI accelerators, etc, are a variety of interfaces. Anytime you have an application framework (or whatever they're called this week), you can have a different interface to even the simplest of things like form variables. Another nice thing about not requiring CGI.pm or libapreq is you can actually feed the formvars from something besides an HTTP submission (useful for page generation into flat html, or for testing). > Likewise, we might consider that CGI.pm is the primary source of > information, but if I pass a db record set to the widget controller > along with CGI.pm, I may want CGI.pm to override the database but if > there is no CGI.pm value, then the value from the database field will > be placed in the widget instead. > > Anyway, I am sorry if this sounds quite odd. I am not good at > explaining things when I am tired, but I did at least want to throw > out the idea of not being married yet to a particular way of having a > widget consume data from a data source. I agree that there are a lot of various issues here for when it comes to handling data input and output. But I think that for something like a Widget set to be useful, it needs to be as decoupled as possible from all external libraries, and still be able to play with them. Now, that means one of two things. (a) Some kind of base class (Some people suggest using an "implied" interface without a true abstract base class that defines the various methods; I am very much against this because it can lead to somewhat sloppy programming. If you're going to use objects, use them in a way that other languages tend to use them and not as typeless chunks that respond to various kinds of black magic poking and prodding). I personally only see this being not-the-best-option because of unnecessary complexity for the fairly simple task at hand. If the task were more complicated, there is no doubt this is the proper route. (b) The other option, a closure, makes the simple things simple, but the harder things a bit harder. File uploads, for instance, and cookies. Of course, since a Widget set rarely (if ever) would need to display the content of an upload as part of a re-rendering of the widget, I don't see this being a common use. Likewise, cookies don't seem as needed to be for more or less the same reason (if you're using raw cookies to pass complex data around, you're probably doing more work than you need to; things like Apache::Session make life easier without forcing you to muck with cookies at every data access point). It gets ugly though if you -do- want cookies. Does your abstract base class (ABT) have to be typed for every possible pair of form var input and cookie input methods? Is there a separate interface for each, thus complicating the API slightly? The more I think about it, the more wrong it seems for the Widget library to assume anything about where its data is coming from. It should either be from a closure or a class based on an ABT. A third option is that all widgets are actually generated by a generator instance of a class; this could simplify the API so that you needn't pass the CGI object or closure around all the time. In this case, you could derive from this base class to create new ways of gathering data from CGI and cookies. This is more or less a standard design pattern -- data interfacing. There are a number of solutions. I just hope whatever gets written is present and future proof enough to not depend on any particular interface (such as CGI or libapreq), or at the very least made to easily use others. You never know when someone else may have another templating technology that has a different interface! Cheers, Chip -- Chip Turner [EMAIL PROTECTED] RHN Web Engineer
Re: Real Widgets and Template Languages
Jay, I think that pretty much describes what I have in mind ... plus a few other features. Hopefully within a week or two (based on demands of other *paying* jobs), I will have a working distribution with most of the bare-bones plumbing in place and a little configurable date widget implemented. This will allow me to solicit feedback on the plumbing and concepts before I go hog wild on implementing a host of widgets. (In fact, I predict the package will be downright boring for a month or more, to those who don't want to shape its development, while I get the concept and the internals right.) I have done the Widget.pm convenience functions and factory code. I am working on the Widget::Config class to read XML config data using XML::Simple. Then on to Widget::Base a parent class for all implemented widgets. Then on to Widget::Controller which will be handed a CGI object (or Apache::Request or whatever using one of the much-commented on schemes) and dispatches events detected from submit buttons, etc. Then I do my first actual widget, Widget::HTML::Date. I'll camp on this while I get lots of feedback. Stephen P.S. I have submitted an application for a Sourceforge project called the "Perl Widget Library". The short name is "perl-widget". I am waiting for approval from Sourceforge. This won't hold me up though. I plan on posting distributions on my web site. At 12:28 PM 5/24/2001 -0400, Jay Lawrence wrote: >Hey all, > >Let me describe what I have been imagining as the ideal widget for what I am >writing: > >1 - it can look to its environment to determine how to render itsself >- am I on an HTML page or something else? >2 - it has properties that can be set and remain static no matter who's >using it >- size, shape, colour, max, min >3 - it has properties that are customized by the individual user of the >widget >- current value, theme choice, >4 - it can tell developers and environments what it can do >- switch_on, switch_off, increment, decrement, etc. >5 - it is capable of persisting from invocation to invocation >- user 1 sets current_value to x - which always comes back for user >1 >6 - it can look to its environment for interhitable properties >- global theme choice, global font, etc. >7 - templating systems know how to call widgets >- because they always use the same method to display themselves >8 - widget can interact with each other >- increasing value on slider widget changes current record # value >for database record widget >9 - access restrctions >- users can override some values but not others >- not everyone can even use this widget, etc. >10 - multilingual >- some things are language neutral others are not - "size" would >probably be neutral whereas "label" would be language sensitive >11 - above all it is easy to use >- ie/ don't make me set a zillion properties just to make it work! > >I am going to throw out a buzzword, gasp, which may serve as a model for >what we are talking about: JavaBeans. I do feel there is a lot of additional >complexity there but it is along the right direction IMHO. > >If you translate my wishlist into technologies I think I am talking about: > >A - a good persistant object management environment >B - user sessions >C - integration of widgets (objects) to user sessions >D - Object API (properties and methods) which are consistant and >predictable >E - self documenting objects > >This is what I have been looking for/writing myself! I am really eager to >chip in on this project and get it going ASAP - but do acknowledge the need >for hearty discussion about what people really want not just my own views. >:)) > >Jay > > > >
Re: credit card processing
[EMAIL PROTECTED] (Doug MacEachern) wrote: >On Wed, 23 May 2001, Adam Prime wrote: >> I was looking through the mod_perl archives and saw a post from doug about a >> credit card processing system called 'creditor' i looked on the covalent >> web site, but i couldn't find any info. Did this thing ever see the light >> of day? > >yes, credator (product spells with an 'a' rather than 'i') Ooh, that sounds like it has some TEETH! =) ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: credit card processing
On Wed, 23 May 2001, Adam Prime wrote: > > I was looking through the mod_perl archives and saw a post from doug about a > credit card processing system called 'creditor' i looked on the covalent > web site, but i couldn't find any info. Did this thing ever see the light > of day? yes, credator (product spells with an 'a' rather than 'i') is part of the 'commerce server' bundle: http://www.covalent.net/products/commerce/
Re: forced win32 mod_perl
* Tom Gioconda ([EMAIL PROTECTED]) [010524 23:03]: > It was my impression that PerlEx handled the persistance and what not, but > it wouldn't allow one to make a content handler using perl. I need some way > of processing every html file through my TemplateHandler::handler method. > The way I was doing this was telling Apache to use my method as the content > handler, instead of Apache just return the results, I was processing the > file and sending those results to the client. PerlEx only does the part that > keeps the perl interpreter running, right? It keeps a pool of interpreters running, and I'd *thought* that you could make something akin to a content handler (by using the directory mapping stuff) but on second thought it doesn't appear so. (I haven't used it for quite some time...) > If it does more, is there documentation that shows how this is done? I > certainly couldn't find anything about content handlers on their sites. I hadn't realized you were so tied to the mod_perl way of doing this, my bad. I heard the magic words 'forced to move to Win2000' and my reflex kicked in :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: compilation: libperl.a
On Thu, 24 May 2001, Chethan Pandarinath wrote: > Hi all, > > I've been trying to compile apache with mod_perl and mod_php support. > I've been following the instructions from the "mod_perl Guide" > [http://perl.apache.org/guide/install.html#mod_perl_and_mod_php] (and > just assuming that it's similar for php3 and php4). > > I haven't been able to get mod_perl to compile in (ie make test fails > for mod_perl, server never "warms up"). One thing that's confused me is > the line in the configuration of Apache right before the build: > --activate-module=src/modules/perl/libperl.a I've compiled php4 and mod_perl following these notes two days ago for the book: Are you sure you did follow the steps exactly? ( you have adjust php3 to php4 for the latest version)/ > Unfortunately even after I make mod_perl, I don't get any libperl.a file > in that directory. The closest thing I get is a libperl.module file. > Does this sound familiar to anyone? Any ideas what I'm doing wrong? > > Sorry if this is an old topic; I searched the archives but couldn't find > anything helpful. it's on topic. Here is a fresh scenario cleaned up for the book, but I think that it's pretty much the same as in the guide: =head2 Installing mod_perl with mod_php The following is a simple installation scenario of a combination mod_perl and mod_php build for the Apache server. Since we aren't going to configure custom installation directory, Apache will use the default I directory. =over =item 1 Download the latest stable source releases: Apache: http://www.apache.org/dist/httpd/ mod_perl: http://perl.apache.org/dist/ PHP: http://www.php.net/downloads.php =item 1 Un-pack: panic% tar xvzf mod_perl-x.xx panic% tar xvzf apache_x.x.x.tar.gz panic% tar xvzf php-x.x.xx.tar.gz =item 1 Configure Apache. panic% cd apache_x.x.xx panic% ./configure =item 1 Build mod_perl: panic% cd ../mod_perl-x.xx panic% perl Makefile.PL APACHE_SRC=../apache_x.x.xx/src NO_HTTPD=1 \ USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 panic% make =item 1 Build mod_php: panic% cd ../php-x.x.xx panic% ./configure --with-apache=../apache_x.x.xx \ --with-mysql --enable-track-vars panic% make panic# make install [F] mod_php doesn't come with I suit, so we don't run it [/F] =item 1 Reconfigure Apache to use mod_perl and PHP and build it: panic% cd ../apache_x.x.xx panic% ./configure \ --activate-module=src/modules/perl/libperl.a \ --activate-module=src/modules/php4/libphp4.a panic% make [F] If you are building PHP3, use I. [/F] =item 1 Test and install mod_perl panic% cd ../mod_perl-x.xx panic% make test panic# make install. =item 1 Complete the Apache installation. panic# cd ../apache_x.x.xx panic# make install =back Now when you start the server: panic# /usr/local/apache/bin/apachectl start you should see something like this in I: [Fri May 18 11:10:31 2001] [notice] Apache/1.3.19 (Unix) PHP/4.0.5 mod_perl/1.25 configured -- resuming normal operations _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
compilation: libperl.a
Hi all, I've been trying to compile apache with mod_perl and mod_php support. I've been following the instructions from the "mod_perl Guide" [http://perl.apache.org/guide/install.html#mod_perl_and_mod_php] (and just assuming that it's similar for php3 and php4). I haven't been able to get mod_perl to compile in (ie make test fails for mod_perl, server never "warms up"). One thing that's confused me is the line in the configuration of Apache right before the build: --activate-module=src/modules/perl/libperl.a Unfortunately even after I make mod_perl, I don't get any libperl.a file in that directory. The closest thing I get is a libperl.module file. Does this sound familiar to anyone? Any ideas what I'm doing wrong? Sorry if this is an old topic; I searched the archives but couldn't find anything helpful. Yours, Chethan -- Chethan Pandarinath Senior, Computer Engineering & Science, Technology and Society NC State University (919) 754-0325 | [EMAIL PROTECTED] | AIM: chetpan http://pandarinath.com
Re: forced win32 mod_perl
It was my impression that PerlEx handled the persistance and what not, but it wouldn't allow one to make a content handler using perl. I need some way of processing every html file through my TemplateHandler::handler method. The way I was doing this was telling Apache to use my method as the content handler, instead of Apache just return the results, I was processing the file and sending those results to the client. PerlEx only does the part that keeps the perl interpreter running, right? If it does more, is there documentation that shows how this is done? I certainly couldn't find anything about content handlers on their sites. >From: Chris Winters <[EMAIL PROTECTED]> >To: Tom Gioconda <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: forced win32 mod_perl >Date: Thu, 24 May 2001 20:44:01 -0400 > >ActiveState sells a (IMO) cheap solution for just this sort of thing: >PerlEx. (http://www.activestate.com/perlex/) > >Chris > >-- >Chris Winters ([EMAIL PROTECTED]) >Building enterprise-capable snack solutions since 1988. _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Getting the wrong URL
On 24 May 2001, [EMAIL PROTECTED] wrote: > I'm having a recurring problem that I can't find comment about in the docs, and > I was wondering if anyone might have some insight on this. > > I have a web site where *everything* is mod_perl handlers. The problem that I'm > seeing is that I will go to the url http://hostname/foo and I get the content > from http://hostname/bar > > This is naturally very distressing me me as the developer, and very confusing > for the user. I suppose it's very likely a problem with my code, rather than > with mod_perl, but if anyone has seen this before and can suggest where I > should be looking. > > This seems to be happening when there is a server error of some variety, and > from then on, until a server restart, users are just getting whatever the last > thing was that that Apache child served. I have not been able to completely > verify this, but I am consistently getting the same (wrong) content from a > particular child, so apparently the particular child just keeps giving me > whatever it served the last time. looks like http://perl.apache.org/guide/porting.html#Exposing_Apache_Registry_secret http://perl.apache.org/guide/porting.html#Sometimes_it_Works_Sometimes_it _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Real Widgets and Template Languages
At 10:22 AM 5/24/2001 -0700, Paul Lindner wrote: >On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote: > > darren chamberlain <[EMAIL PROTECTED]> writes: > > > > The nice thing about closures is they could hide any interface at all > > behind them; all that is required is that the function that generates > > the closure follow the very simple convention of "return the formvar > > of the name starting with the first parameter you're called with." > > There is absolutely no reliance upon the underlying object structure. > > What you're suggesting is equivalent to assuming the object is derived > > from some kind of base class that supports the param() method though > > without actually having to be ISA of that class. That's naughty OO > > programming :) Just because perl lets you be typeless doesn't mean > > it's always in the best interest of clean design to do so. > >I don't find a problem with passing an object that has a certain set >of method signatures. This is functionally loosely equivalent to a >Java Interface.. Any perl object can implement a particular interface >just by implementing the methods.. No base class required.. > >But I agree, closure are very cool, and allow for an additional layer >of abstraction between the objects, without having to create a proxy >class.. I think closures would only be cool for performance. I personally do not think it is very intuitive. This is OK if the only things we consider supporting as data sources for the widget are Apache::Request and CGI.pm. However, I think it is reasonable to make the interface to support a data source for the widgets flexible and object based to make it easy for someone to write a DBI source, a DBM source, an LDAP source, an Apache::Session source or whatever anyone wants really. I happen to think DBI and Session sources are cool. This also leads us to the idea of data handlers. We realized early on that model-view-controller doesn't mean just templates because templates only understand OUTPUT part of the view. The INPUT part of the view is just as important and in many cases can be divorced from business logic for most simple validations. This led us to do a data handler architecture (ie http://www.extropia.com/development/webware2/chap12.pdf) The idea of widgets ties very closely into this because just as widgets require a data source to be populated, widgets themselves should have some capability (through get and set methods) to act as a data source themselves. Either to our data handler architecture or... and this is also "cool", to other widgets. It's entirely conceivable that you want the capability of other widgets on the screen to have different defaults based on the values of other widgets. The rules for "chaining" the data sources into a widget could be as simple as that -- chaining. By default, it could be GPC chaining like PHP (Get, Post, Cookie) But with enough widget data sources to choose from you could do GPCSD (Get, Post, Cookie, Session, Database) type of thing. This may sound like an overengineered design, but the reality is that most casual developers will just use GPC like PHP does. It's when you get into more sophisticated requirements for the app that such a thing becomes more useful. This means that the data sources themselves can be accumulated slowly but the interface to support them should be relatively easy. > > Closures are excellent in hiding implementation details of simple > > operations, and I think in this case they fit quite well. The system > > can even be written to work just fine without the user using closures > > if they're using CGI.pm, as in my previous example. I think but am not sure that closures likely also have better performance than method lookups. If this is the case, it could make sense to support a few data sources that need high performance because of their common use: CGI.pm and Apache::Request. Yet provide the extensibility for other developers to inject their own data sources into the chain using an Object-based API. Maybe someone else could comment on the technical merit of closure vs objects as well as the way in which they have been expecting the widgets to get populated? Is what I am saying make sense? Thanks, Gunther
ANNOUNCE: Soup (0.2) (fwd)
so who's doing the perl wrappers? -- Forwarded message -- Date: 22 May 2001 23:48:06 -0400 From: Alex Graveley <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: ANNOUNCE: Soup (0.2) Ximian is happy to announce the first release of Soup, a Simple Object Access Protocol (SOAP) implementation in C. About SOAP: == SOAP is a generic RPC mechanism, which uses XML for data and type encoding and is transferred over protocols such as HTTP and SMTP. It is language and operating system agnostic, and very lightweight. The immediate benefits to SOAP over other RPC mechanisms such as CORBA or COM are that it functions well through firewalls and is easily encryptable. Some of the more interesting aspects are SOAP's rich type system, built on the emerging XML Schema W3C spec, and the ability to interoperate with other RPC mechanisms. About Soup: == Soup provides a queued asynchronous callback-based mechanism for sending and servicing SOAP requests, and a WSDL (Web Service Definition Language) to C compiler which generates client stubs and server skeletons for easily calling and implementing SOAP methods. It uses the GLib main loop and is designed to work well with GTK applications. Features: * Completely Asynchronous * Connection cache * HTTP chunked transfer and persistent connections * authenticated HTTP, SOCKS4, and SOCKS5 proxy support * SSL Support using OpenSSL * Apache module server support * Client digest authentication * WSDL Compiler Availability: Download the latest tarball at: ftp://ftp.gnome.org/pub/GNOME/unstable/sources/soup/soup-0.2.tar.gz Or from GNOME CVS, in the "soup" module. Also, please feel free to join to the Soup discussion list. To subscribe, send mail with the word "Subscribe" in the message body to [EMAIL PROTECTED] To learn more about SOAP, XML Schema, or WSDL, follow: * http://www.w3.org/XML/Schema(XML Schema home) * http://www.w3.org/TR/SOAP/ (SOAP 1.1 spec) * http://msdn.microsoft.com/xml/general/wsdl.asp (WSDL 1.1 spec) * http://www.develop.com/soap/default.htm (Developmentor SOAP home) * http://msdn.microsoft.com/soap/default.asp (Microsoft SOAP home) -- make: *** No rule to make target `sense'. Stop. ___ gnome-announce-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gnome-announce-list
Re: Appending Sessionid to all the urls
Opps forgot to CC the list
--
Cheers Stuart
---
New Zealand Revolution
[EMAIL PROTECTED]
+64 9 918 7663
On 24 May 2001 14:57:09 -0700, ___cliff rayman___ wrote:
>
>
> Stuart Frew wrote:
>
> > On 24 May 2001 14:21:32 -0700, ___cliff rayman___ wrote:
> > > i'd still use a cookie to indentify the user. why not include
> > > the client id as part of the submission from the browser. it
> > > is easy to keep detailed data in the cookie separate for each client
> > > $sessionData{$clientKey}{$clientDataStuff}=$in{DATAKEY}
> > >
> > snip.
> > Yup you could encode the client ID in to each form but,
> > * If I was to do that I would encode the session ID, and kill to birds
> > with one piece of code.
>
> encoding the session id is much more difficult as u have now found out.
> which two birds do you kill?
>
> >
Ah ah I think I see a difference. I am not using the session ID to track
the user, but the track which client/customer the user is processing and
what they are doing.
We Identify the user by $r->connection->user.
I would use encode the session ID into the form to differentate the two
clients the single user is processing.
For us two windows means two sessions.
Yup, could encode it all into one session but see below...
> > * the joys of sessions is that that the state, via the session ID, is
> > avaiable automagicly without having to code it into each page.
>
> hmmm. i think u r misunderstanding my suggestion - or - u r not fully explaining
> what u r trying to do. look up the html tag. stick that with
>the
> client id somewhere between your tags. everytime the user submits the form,
> the client id will be submitted also. assuming that %in comtains all the forms
>posted
> fields then:
> $session{$in{CLIENTID}}{DATAFIELD1}=$in{DATAFIELD1}
>
> or more generically (untested - could have typos):
>
> $session{$in{CLIENTID}}{$_}=$in{$_} for (grep {!/CLIENTID/, keys %in};
>
But what happens when we go to a page that contains only look up
information.
Say we are on a page that has the main data entry form, but there are
links to lookup pages, such as the client/customers previous purchases.
I don't want to encode the client ID on every link when I can use the
state information with in the lookup page to find out what the
client/customer is.
Also Apache::Session only sees changes at the top level.
So for ever state change we would have to programaticly make the session
aware of the change.
Ok not particulary hard or arduous but why take the risk?
Cheers Stuart
---
New Zealand Revolution
[EMAIL PROTECTED]
+64 9 918 7663
Re: forced win32 mod_perl
* Tom Gioconda ([EMAIL PROTECTED]) [010524 20:06]: > My company, to my objections, recently decided to force all of our new > servers to running only Win2k. I won't go into the details, but let's just > say that in our standard hosting facilities, nothing runing Linux is allowed > anymore. This kinds of screws my department, as we have just finished > development on a Linux/Apache solution tied heavily into mod_perl for a > support web site. > > This leaves me with few options: > 1) Run Apache/win32 and mod_perl. > 2) Run IIS 5 and use an ISAPI handler to hook into my perl code. > > Could anyone help me out here? The first option is bad because of > mod_perl's reduced functionality on win32 in version 1.25 (no threads, to my > understanding). Option 2 is evil because I'd have to figure out some way to > get an ISAPI extension to call perl code in a multithreaded way, and I'd > have to use IIS. > > Am I stuck waiting for Apache 2 and mod_perl 2 to get to a point where > they'll work in a production environment, or am I simply screwed and have to > work around my company's dumb decree? Any help would be appreciated, > although no comments on my company's IT policies, please... :) ActiveState sells a (IMO) cheap solution for just this sort of thing: PerlEx. (http://www.activestate.com/perlex/) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
forced win32 mod_perl
My company, to my objections, recently decided to force all of our new servers to running only Win2k. I won't go into the details, but let's just say that in our standard hosting facilities, nothing runing Linux is allowed anymore. This kinds of screws my department, as we have just finished development on a Linux/Apache solution tied heavily into mod_perl for a support web site. This leaves me with few options: 1) Run Apache/win32 and mod_perl. 2) Run IIS 5 and use an ISAPI handler to hook into my perl code. Could anyone help me out here? The first option is bad because of mod_perl's reduced functionality on win32 in version 1.25 (no threads, to my understanding). Option 2 is evil because I'd have to figure out some way to get an ISAPI extension to call perl code in a multithreaded way, and I'd have to use IIS. Am I stuck waiting for Apache 2 and mod_perl 2 to get to a point where they'll work in a production environment, or am I simply screwed and have to work around my company's dumb decree? Any help would be appreciated, although no comments on my company's IT policies, please... :) -Tom _ Get your FREE download of MSN Explorer at http://explorer.msn.com
mod_perl and keepalive. Jep, yet again.
Morning, this has come up a few times before, but I haven`t found the exact answer yet. I want to test if enabling keep-alive makes some pages load faster. I know the disadvanteges (could use massive amounts memory), but hey, it might just work. I`m using the wellknown browser<->mod_rewrite/proxy<->mod_perl setup. The mod_rewrite apache has keepalive on, the mod_perl one has not. For the record: I want only to enable keepalive between the browser and the frontend apache. Using the 'Connection: Keep-alive' header in cgi scripts on the frontend apache does work; the connections stay open. The same trick doesn`t work with the mod_perl one; mod_proxy does an explicit ap_table_unset(headers, "Connection"); in clear_connection(). Why is that? Is there a way to enable keepalives? Or is it really that bad/not usefull? I did find a patch by Joe Schaefer which looks nice: http://marc.theaimsgroup.com/?l=apache-modperl&m=96787783412579&w=2 Is anybody using it? Thanks, Harmen. -- The Moon is Waxing Crescent (4% of Full) nieuw.nl - 2dehands.nl
Re: Appending Sessionid to all the urls
i'd still use a cookie to indentify the user. why not include
the client id as part of the submission from the browser. it
is easy to keep detailed data in the cookie separate for each client
$sessionData{$clientKey}{$clientDataStuff}=$in{DATAKEY}
Stuart Frew wrote:
> > This is an even more pronounced problem with sessions IDs in
> > URLs, though. With cookie based session tracking, the second
> > browser window will send the same cookie that the first browser
> > window received.
> >
>
> And there lies the rub.
>
> The user is using the system to process client A. The cookie contains
> stateful information including the client ID.
>
> They then open an new browser window, and lookup client B, recieving a
> new session ID with new state information, including the client ID.
>
> The user then submits the form to the server.
>
--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
Getting the wrong URL
I'm having a recurring problem that I can't find comment about in the docs, and I was wondering if anyone might have some insight on this. I have a web site where *everything* is mod_perl handlers. The problem that I'm seeing is that I will go to the url http://hostname/foo and I get the content from http://hostname/bar This is naturally very distressing me me as the developer, and very confusing for the user. I suppose it's very likely a problem with my code, rather than with mod_perl, but if anyone has seen this before and can suggest where I should be looking. This seems to be happening when there is a server error of some variety, and from then on, until a server restart, users are just getting whatever the last thing was that that Apache child served. I have not been able to completely verify this, but I am consistently getting the same (wrong) content from a particular child, so apparently the particular child just keeps giving me whatever it served the last time. -- The Creative Group Web Application Group Moving your paper processes to your intranet site
Re: Appending Sessionid to all the urls
At 08:39 25.05.2001 +1200, you wrote: >And there lies the rub. > >The user is using the system to process client A. The cookie contains >stateful information including the client ID. > >They then open an new browser window, and lookup client B, recieving a >new session ID with new state information, including the client ID. Why are you doing this. client B probably sends a valid session ID, so why does he get a new one? >(Oh and telling the users 'Don't Do That' does not work either :^) Never does. Joachim -- "... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen."- Bertolt Brecht - Leben des Galilei
Re: Appending Sessionid to all the urls
> This is an even more pronounced problem with sessions IDs in > URLs, though. With cookie based session tracking, the second > browser window will send the same cookie that the first browser > window received. > And there lies the rub. The user is using the system to process client A. The cookie contains stateful information including the client ID. They then open an new browser window, and lookup client B, recieving a new session ID with new state information, including the client ID. The user then submits the form to the server. The server then recives the one and only cookie with a session ID in it. But is it for Client A or Client B? 50-50 chance of updating the right row. Not good. With the session ID in the URL, once the new session ID is issued you know which browser window, and hence data, the session is for and hence update the correct row. Of course if anyone knows how to make it work with cookied I'd love to know. Cheers Stuart (Oh and telling the users 'Don't Do That' does not work either :^) -- Cheers Stuart --- New Zealand Revolution [EMAIL PROTECTED] +64 9 918 7663
RE: Real Widgets and Template Languages [resend]
[[ This is a resend.. did some cutting and pasting of code into telnet
windows that messed it up through shell expansion. My bad. ]]
I have a couple modules that might be the start of what you are calling a
Widget system. I'm not sure if my modules are in line with the thoughts
expressed on this list. Pardon me if this is something different: I've been
loosely following this discussion..
Using my library, whenever I want a form I specify in one list all of the
elements along with the type of data and any validation routines. Some
information about how the form should look is also included. My code then
automatically generates the form (it looks like a dialogue box) from this
information. The same informational hash is used to parse the form and
validate the data. If the data is not validated correctly, the form is shown
again with the validation errors and the data remaining sticky. If the data
is validated then it is returned in a hash.
Here is a simplified example of the widget definitions for a form that
allows a customer to charge money on their credit card into their balance:
[
amount => { width => "20", same_line => 1,
label => "Amount to charge (in dollars)", _label => "Amount to
charge",
_looks_like => "number", _required => 1, },
[{ addl_require => [{
type => "sub",
fields => [qw(amount)],
sub => sub {
my ($require, $values, $labels) = @_;
return "You may not initiate a charge for less than \$5.00."
if ( $values->[0] < 5 );
return "You may not initiate a charge for more than \$900.00. If
you really do want to
charge this much, then you need to call us and we can do it
for you."
if ( $values->[0] > 900 );
return undef;
},
}], }],
]
Note the elements "label", "_label", and "same_line" for the "amount" widget
specify display attributes. (My actual definition of the form contains more
than the widgets themselves but rather the whole look and feel form.) The
element "_required" specifies that this widget may not be left blank by the
user. The element "_looks_like" with value "number" specifies that the value
in this text box must be a number. I can also specify dates, free text, or
whatever I needed as types for the widget.
The "addl_require" stuff you see is a way of in lining an additional
requirement: this requires that the value for the amount field must be
between 5.00 and 900.00. The additional requirement is tied specifically to
the fields that it is dependent on. For example, if the field "amount" was
left blank thus not satisfying the "_required" specification, then this
addl_require you see would not be checked, as its dependants has not been
verified.
Here is another example. This is the definition for the form elements to
collect credit card information:
[
[qq[ ]],
card_type => { c_table => 1, et => "select", label => "Card type",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__card_type->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__card_type__keys
],
},
card_num => { c_table => 1, width => 30, label => "Card number" },
[{ addl_require => [{
type => "sub",
fields => [qw(card_num)],
sub => sub {
my ($require, $values, $labels) = @_;
return "The credit card number you entered is not valid."
if ( not Business::CreditCard::validate($values->[0]) );
return undef;
},
}], }],
[qq[ Expiration ]],
exp_month => { c_blank => 1, et => "select", label => "Exp month",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__exp_month->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__exp_month__keys
],
},
[qq[ / ]],
exp_year => { c_blank => 1, et => "select", label => "Exp year",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__exp_year->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__exp_year__keys
],
},
[qq[ ]],
[q[
If the name on the card is different than your billing
address you can enter it below.
]],
card_name => { width => 30, c_table => 1, label => "Name on card" },
[qq[ ]],
]
This above code is showing the strains of evolution of my system. :-) Notice
all the [qq[ ... ]] constructs which allow HTML text to be inlined.
Originally there wasn't much inlined HTML, as each widget knew how to
display itself and its label. However I was stuck to one specific display
look constrained me. So I told the widgets how to print their labels with
"c_blank" and "c_table" parameters and inlined HTML code.
This really calls for the widgets to be embedded directly in the HTML
template which contains the formatting a la that
Gunther proposed.
This above code actually sits in a subroutine that returns a list of the
definitional information. This list is then simply includ
RE: Real Widgets and Template Languages
I have a couple modules that might be the start of what you are calling a
Widget system. I'm not sure if my modules are in line with the thoughts
expressed on this list. Pardon me if this is something different: I've been
loosely following this discussion..
Using my library, whenever I want a form I specify in one list all of the
elements along with the type of data and any validation routines. Some
information about how the form should look is also included. My code then
automatically generates the form (it looks like a dialogue box) from this
information. The same informational hash is used to parse the form and
validate the data. If the data is not validated correctly, the form is shown
again with the validation errors and the data remaining sticky. If the data
is validated then it is returned in a hash.
Here is a simplified example of the widget definitions for a form that
allows a customer to charge money on their credit card into their balance:
[
amount => { width => "20", same_line => 1,
label => "Amount to charge (in dollars)", _label => "Amount to
charge",
_looks_like => "number", _required => 1, },
[{ addl_require => [{
type => "sub",
fields => [qw(amount)],
sub => sub {
my ($require, $values, $labels) = @_;
return "You may not initiate a charge for less than \$5.00."
if ( $values->[0] < 5 );
return "You may not initiate a charge for more than \$900.00. If
you really do want to
charge this much, then you need to call us and we can do it
for you."
if ( $values->[0] > 900 );
return undef;
},
}], }],
]
Note the elements "label", "_label", and "same_line" for the "amount" widget
specify display attributes. (My actual definition of the form contains more
than the widgets themselves but rather the whole look and feel form.) The
element "_required" specifies that this widget may not be left blank by the
user. The element "_looks_like" with value "number" specifies that the value
in this text box must be a number. I can also specify dates, free text, or
whatever I needed as types for the widget.
The "addl_require" stuff you see is a way of in lining an additional
requirement: this requires that the value for the amount field must be
between 5.00 and 900.00. The additional requirement is tied specifically to
the fields that it is dependent on. For example, if the field "amount" was
left blank thus not satisfying the "_required" specification, then this
addl_require you see would not be checked, as its dependants has not been
verified.
Here is another example. This is the definition for the form elements to
collect credit card information:
[
[qq[ ]],
card_type => { c_table => 1, et => "select", label => "Card type",
options => [
map { [ ::DbAccess::Lookup::ccard__card_type->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__card_type__keys
],
},
card_num => { c_table => 1, width => 30, label => "Card number" },
[{ addl_require => [{
type => "sub",
fields => [qw(card_num)],
sub => sub {
my (, , ) = @_;
return "The credit card number you entered is not valid."
if ( not Business::CreditCard::validate(->[0]) );
return undef;
},
}], }],
[qq[ Expiration ]],
exp_month => { c_blank => 1, et => "select", label => "Exp month",
options => [
map { [ ::DbAccess::Lookup::ccard__exp_month->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__exp_month__keys
],
},
[qq[ / ]],
exp_year => { c_blank => 1, et => "select", label => "Exp year",
options => [
map { [ ::DbAccess::Lookup::ccard__exp_year->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__exp_year__keys
],
},
[qq[ ]],
[q[
If the name on the card is different than your billing
address you can enter it below.
]],
card_name => { width => 30, c_table => 1, label => "Name on card" },
[qq[ ]],
]
This above code is showing the strains of evolution of my system. :-) Notice
all the [qq[ ... ]] constructs which allow HTML text to be inlined.
Originally there wasn't much inlined HTML, as each widget knew how to
display itself and its label. However I was stuck to one specific display
look constrained me. So I told the widgets how to print their labels with
"c_blank" and "c_table" parameters and inlined HTML code.
This really calls for the widgets to be embedded directly in the HTML
template which contains the formatting a la that
Gunther proposed.
This above code actually sits in a subroutine that returns a list of the
definitional information. This list is then simply included other places so
I can write stuff like this:
[
[qq[
Enter your billing information and credit card.
]],
[qq[ Billing information ]],
[{ default_b
Re: Real Widgets and Template Languages
On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote: > darren chamberlain <[EMAIL PROTECTED]> writes: > > The nice thing about closures is they could hide any interface at all > behind them; all that is required is that the function that generates > the closure follow the very simple convention of "return the formvar > of the name starting with the first parameter you're called with." > There is absolutely no reliance upon the underlying object structure. > What you're suggesting is equivalent to assuming the object is derived > from some kind of base class that supports the param() method though > without actually having to be ISA of that class. That's naughty OO > programming :) Just because perl lets you be typeless doesn't mean > it's always in the best interest of clean design to do so. I don't find a problem with passing an object that has a certain set of method signatures. This is functionally loosely equivalent to a Java Interface.. Any perl object can implement a particular interface just by implementing the methods.. No base class required.. But I agree, closure are very cool, and allow for an additional layer of abstraction between the objects, without having to create a proxy class.. > Closures are excellent in hiding implementation details of simple > operations, and I think in this case they fit quite well. The system > can even be written to work just fine without the user using closures > if they're using CGI.pm, as in my previous example. -- Paul Lindner [EMAIL PROTECTED]
Re: Real Widgets and Template Languages
Related to the previous discussion of closures vs object interface (eg
param) for getting CGI form data into the widgets:
While I think that it is clever to allow an interface to change where the
parameters come from, I think in practice there are different things to
expect. eg how to deal with multi-values? How to deal with file upload
field? I think there are quirks in various libraries.
I do not think these things are insurmountable. And Chip's suggestion
stands a good chance of working. I do also think there are so few libraries
to deal with parameters that it would not be an unreasonable design
decision to make the Widget controller hard code knowledge of CGI.pm,
Apache::Request and any others since there really aren't many.
At least at first cut. If it looks like there are too many data sources of
widget data to deal with then it has to be dealt with.
I would also offer the possibility that the data source for a widget should
not solely be a CGI.pm object but could conceivably come from many types of
data sources and that these data sources might have priorities yet all
apply to the same widget controller. Let's take a lesson (not necessarily
one to be followed) from PHP. In PHP, variables come into existence
automatically. But there are rules that are followed.
eg Cookies, Get,. Post which means that if the variable is somehow
resulting from a cookie instantiate the var as a the value of the cookie.
If there is a GET param of the same name, override the var with the value
of the Get param, and if there is a POST as well, then override the value
from $ENV{QUERY_STRING} with the value from the POST.
Likewise, we might consider that CGI.pm is the primary source of
information, but if I pass a db record set to the widget controller along
with CGI.pm, I may want CGI.pm to override the database but if there is no
CGI.pm value, then the value from the database field will be placed in the
widget instead.
Anyway, I am sorry if this sounds quite odd. I am not good at explaining
things when I am tired, but I did at least want to throw out the idea of
not being married yet to a particular way of having a widget consume data
from a data source.
Re: Real Widgets and Template Languages
At 08:50 PM 5/23/01 -0400, Adi Fairbank wrote: >Stephen, > >I read your proposal and I like it a lot. I will help filling out the >HTML::Widget::HTML* space (in your package structure suggestion). > >However, I like Gunther's suggestion for a namespace of Widget:: better than >HTML::Widget::, because it will not be exclusively HTML, but WML, JS10, >etc. But either one is fine with me. What is JS10? JavaScript version 1.0? Should we call it JavaScript or EcmaScript? :) I actually think that Perl objects to generate JS validation routines is worthy of its own abstraction. There are several reasons for this. One is that you need to be able to decouple the javascript tags. So if you validate, say, a text field to contain only numbers, the routine to do it should be in the header of the HTML but the widget that gets drawn needs to reference the right routine. So such a library that can generate this stuff needs to be a little more wise and the new JS tags have to be intelligent to know about each other so that a tag at the top of the page that generates the routines can know ahead of time what routines to generate based on the widgets that appear later in the page. It seems solvable but also a bit hard and scary. While it is possible to make JS-specific components (as a first cut)... I wouldn't want to lose site of the fact that the JS could be an add-on and maybe it is possible that it should be it's own abstract that the widget set needs to be able to hook into but isn't built into separate widgets. The red flag comes in seeing examples like Widget::HTML::DateDropDown Widget::HTML::UserAgentDate Widget::HTML::JSDate if it is like this, then you may have many date widgets flying aroudn that are all HTML widgets but share features with a lot of copy and paste between them which isn't very clean OO. As I write this I am quite sleepy and so please forgive my lack of constructive critique. I just want to point it out and maybe we can revisit this. We don't have to code the JS abstraction but if it is clearly outlined where stuff like JS should interact with the widget library and where it should not, then it will make the job of developing the widget library easier. >Sounds fun! I agree!
Re: Real Widgets and Template Languages
Hey all, Let me describe what I have been imagining as the ideal widget for what I am writing: 1 - it can look to its environment to determine how to render itsself - am I on an HTML page or something else? 2 - it has properties that can be set and remain static no matter who's using it - size, shape, colour, max, min 3 - it has properties that are customized by the individual user of the widget - current value, theme choice, 4 - it can tell developers and environments what it can do - switch_on, switch_off, increment, decrement, etc. 5 - it is capable of persisting from invocation to invocation - user 1 sets current_value to x - which always comes back for user 1 6 - it can look to its environment for interhitable properties - global theme choice, global font, etc. 7 - templating systems know how to call widgets - because they always use the same method to display themselves 8 - widget can interact with each other - increasing value on slider widget changes current record # value for database record widget 9 - access restrctions - users can override some values but not others - not everyone can even use this widget, etc. 10 - multilingual - some things are language neutral others are not - "size" would probably be neutral whereas "label" would be language sensitive 11 - above all it is easy to use - ie/ don't make me set a zillion properties just to make it work! I am going to throw out a buzzword, gasp, which may serve as a model for what we are talking about: JavaBeans. I do feel there is a lot of additional complexity there but it is along the right direction IMHO. If you translate my wishlist into technologies I think I am talking about: A - a good persistant object management environment B - user sessions C - integration of widgets (objects) to user sessions D - Object API (properties and methods) which are consistant and predictable E - self documenting objects This is what I have been looking for/writing myself! I am really eager to chip in on this project and get it going ASAP - but do acknowledge the need for hearty discussion about what people really want not just my own views. :)) Jay
Re: Appending Sessionid to all the urls
Yeah, create a safe link jumping point. Something that you'd link to instead of the external link, and pass in the external link, without a session_id so that the HTTP_REFERER won't have the session ID. Don't rely on IP address for more reasons then you mentioned... It might not hurt to implement some kind of "time out" feature too. It's you and a dagger against an army. Jay On Thu, 24 May 2001, stefan weiss wrote: > From: <[EMAIL PROTECTED]> > > > A better way for session ids is to put them in front of the URI: > > http://www.nus.edu.sg/dfd3453/some/path/and/file.html > (...) > > These session ids are sticky as long as you only use relative paths in your > > html. Note: You may want to put your images in a directory that's not covered by > > this handler and use absolute paths... > > > But wouldn't the session ID get sent to other (possible malicious) servers > as well - in the HTTP_REFERER, if the user clicks on an external link? > That might enable a script on that other server to grab your user's session. > I guess you could add an additional check including the original user's IP > address, but that's not really safe either. People working in the same > company could spy on each other if they use the same HTTP proxy. > > Any known workarounds for this? > > > cheers, > stefan > > >
Re: Appending Sessionid to all the urls
From: <[EMAIL PROTECTED]> > A better way for session ids is to put them in front of the URI: > http://www.nus.edu.sg/dfd3453/some/path/and/file.html (...) > These session ids are sticky as long as you only use relative paths in your > html. Note: You may want to put your images in a directory that's not covered by > this handler and use absolute paths... But wouldn't the session ID get sent to other (possible malicious) servers as well - in the HTTP_REFERER, if the user clicks on an external link? That might enable a script on that other server to grab your user's session. I guess you could add an additional check including the original user's IP address, but that's not really safe either. People working in the same company could spy on each other if they use the same HTTP proxy. Any known workarounds for this? cheers, stefan
Re: Real Widgets and Template Languages
darren chamberlain <[EMAIL PROTECTED]> writes:
> Chip Turner ([EMAIL PROTECTED]) said something to this effect on 05/23/2001:
> > If I could make a suggestion -- don't depend upon a CGI.pm interface
> > for form variables. Abstract it away. One option would be to use
> > closures:
>
> I agree with not relying upon CGI, but using closures still
> requires some knowledge of the object type. Something simpler
> would be to assume that an object passed in has a param method
> that behaves the way CGI.pm's and Apache::Request's param do.
> Something like:
Not true at all.
my $cgi = new CGI;
my $cgi_param = sub { return $cgi->param(shift) };
my $asp_param = sub { return $Request->{+shift} };
etc
The nice thing about closures is they could hide any interface at all
behind them; all that is required is that the function that generates
the closure follow the very simple convention of "return the formvar
of the name starting with the first parameter you're called with."
There is absolutely no reliance upon the underlying object structure.
What you're suggesting is equivalent to assuming the object is derived
from some kind of base class that supports the param() method though
without actually having to be ISA of that class. That's naughty OO
programming :) Just because perl lets you be typeless doesn't mean
it's always in the best interest of clean design to do so.
Closures are excellent in hiding implementation details of simple
operations, and I think in this case they fit quite well. The system
can even be written to work just fine without the user using closures
if they're using CGI.pm, as in my previous example.
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Appending Sessionid to all the urls
Stuart Frew ([EMAIL PROTECTED]) said something to this effect on 05/23/2001: > Greetings, > > One problem with using cookies for session management is that the user > can have two browsers open doing the same process. > > Which means the first cookie Session ID will be over writen by the > second one. Which can lead to horrid results if the user continues the > first process but has the session ID from the second process. > > May not be an issue out in the Internet but is a true pain in an > intranet environment. This is an even more pronounced problem with sessions IDs in URLs, though. With cookie based session tracking, the second browser window will send the same cookie that the first browser window received. At least that's how sane browsers operate. (darren) -- It is impossible to experience one's death objectively and still carry a tune. -- Woody Allen
Re: Real Widgets and Template Languages
Chip Turner ([EMAIL PROTECTED]) said something to this effect on 05/23/2001:
> If I could make a suggestion -- don't depend upon a CGI.pm interface
> for form variables. Abstract it away. One option would be to use
> closures:
I agree with not relying upon CGI, but using closures still
requires some knowledge of the object type. Something simpler
would be to assume that an object passed in has a param method
that behaves the way CGI.pm's and Apache::Request's param do.
Something like:
my $q = CGI->new;
# or:
# my $q = Apache::Request->new($r);
# and so on.
my $widget = Widget::Controller->new('factory' => $q);
(I made up the term 'factory'; I hope it's clear what I mean from
the context.)
# Widget::Controller:
sub new {
my $class = shift;
my %args = @_;
# stuff...
if (defined $args{'factory'} &&
UNIVERSAL::can($args{'factory'}, 'param'))
{
$self->{'factory'} = $args->{'factory'};
}
# more stuff
}
This way, anything with a params method can be used. I am unsure
about whether Apache::ASP has a param method, but perhaps one
could be added:
# Apache::ASP
sub param {
my $self = shift;
my $what = shift;
if (defined $Request->Form->{$what}) {
return $Request->Form->{$what};
} ## ^ what is this called?
# more stuff
}
Or whatever. You get the idea.
So, from within the Widget object or a subclass, you call:
my $val = $widget->factory->param('foo');
... and it doesn't matter what the factory is. This breaks down
with modules like HTML::Template which have a param method that
does completely different things, and (possibly) modules that
AUTOLOAD methods.
> That way the user can easily give you different sources of formvars
> (libapreq, Apache::ASP's hash, plus others not yet public) and yet you
> still get the flexibility you need.
It seems to me that, because CGI.pm has become the standard, and a
lot of people have experience programming CGI scripts with it, it
has become pretty standard for CGI-ish modules to have param
methods that behave like CGI.pm's does. This assumption is
underlying the above suggestion. Is that a good assumption?
Littering the code with tons of "if ref $_[0] eq 'ThisModule'"
seems ugly and hard to maintain, and has the potential to
introduce bugs and unintentional omissions too quickly.
> I would suggest using a class for this kind of thing, but
> realistically it's a bit much to expect users to derive classes just
> for something as simple as this. By supporting the coderef closure
> internally, you don't force users to understand what's going on, but
> still allow for more advanced users to use different interfaces. Plus
> you remove dependance on a web server.
I agree with you--it's the Right Thing To Do, but we aren't
writing Java here. Liberal use of UNIVERSAL::can should be all
that is needed to handle this situation.
A Widget::DefaultFactory (or whatever) class should be provided,
to be used by default, which has an empty param method.
As an aside, I like the approach the Template Toolkit takes for
using subclasses or replacements for internal functionality.
Defining your own module to be used internally (for example, a
new Provider, which is what reads the template file from disk or
a cache), you set $Template::Config::PROVIDER to the classname of
your replacement, and the other Template modules get the right
class by doing something like:
$Template::Config::PROVIDER = 'My::Groovy::Provider';
my $provider = Template::Config->provider(\%options);
And the right type of object gets returned (Template::Config
loads the module when it is called). My only complaint
about this is that the interface (assigning to a global) could be
cleaner.
Just some thoughts.
(darren)
--
The first human who hurled an insult instead of a stone was the founder of
civilization.
-- Sigmund Freud
Re: Appending Sessionid to all the urls
On Thu, May 24, 2001 at 08:20:01AM +1200, Stuart Frew wrote: > Greetings, > > One problem with using cookies for session management is that the user > can have two browsers open doing the same process. > > Which means the first cookie Session ID will be over writen by the > second one. Which can lead to horrid results if the user continues the > first process but has the session ID from the second process. > > May not be an issue out in the Internet but is a true pain in an > intranet environment. Can't you write your code to cope with this situation? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Real Widgets and Template Languages
> I will step up to write this code. (if it is what I think it is) > I have responded to the message by beginning a requirements document. > >http://www.officevision.com/pub/HTML-Widget/ > > Please read it and send me any comments. > The following are the questions I need advice on in order to proceed. > > * What CPAN package namespace should I use? > I studied the existing packages, and what we are trying to do looks > like it fits under the existing top level package HTML. > I propose to take the space "HTML::Widget" (see package layout in > design doc). Gunther suggested the top-level "Widget" name space. > I was under the impression that we should stay away from creating > new top-level entries at CPAN unless there was really *nothing* > similar. Confusingly, there is already an HTML::Widgets. Thoughts? First, I think it's not important to get started with. I think we can start with Widget:: given that the code is not strongly tied to HTML. In fact think of the email templates where you want the widget to do the right thing when a respond is sent via email and not HTML (not talking about certain companies who want the emails to be sent in HTML). Once we have more code written, we can talk to the CPAN gods (Andreas Koenig and alike) and particularly comp.languages.perl.modules news group which is supposed to deal with it. If the class is well abstracted I don't think there will be a resistance to start a new namespace. But I think that a pure intention is not good enough to convince people. A working code always makes things easier. If the choice of the namespace will be proven to be wrong we can easily s/Widget::/Rocket::/ and do the filename renaming. So it's a non-issue I think. > * What CPAN packages should I begin with and build upon? > CGI and Apache::Request were mentioned. I figure I will use these. > HTML::StickyWidgets was also mentioned. Do you mean HTML::StickyForms? > Are there others I should build dependencies on? I think we are talking about thing that should be very abstract, so you probably can use whatever you feel comfortable with, probably CGI.pm/Apache::Request on one side and CGI.pm/HTML::StickyForms on the other side to start with. But we have to make sure that other packages will be easily plugged in. This is something that we call 'drivers' in our extropia.com ADT, you need only to write a driver for a particular service/module to make use of this service/module, without changing your applications. Well you know that already from DBI:: world. Then later on someone will come up with a plugin for TT and other templating systems... > * Should I begin immediately with a new Sourceforge project? another way? > The codebase I will begin with is in CVS on my local server. > Perhaps I should just continue that way and post versions to CPAN > for distribution. However, we may have email traffic for the project > that exceeds the general interests of the modperl list. Thoughts? > I would need to get enough responses from people who would join that > Sourceforge mailing list before it would be worth it to go do that. sourceforge is a good idea as it gives you a public cvs and mailing lists. (bug tracking and etc). I don't think that things should be placed on CPAN yet. Once you have a working version, that's when it should get released on CPAN. Of course these are only my thoughts... :) As the leader of the project you decide how you want things to be done, and we can just try to push you into the _right_ direction :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
