You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
(3) |
Nov
|
Dec
|
2002 |
Jan
(1) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
From: Matti L. <mat...@he...> - 2003-10-01 07:35:38
|
Wrenn, Bobby J. wrote: >After following the brief install instructions and adding index.cgi as a >default web page in httpd.conf, I get the source listing when I try to view >cms/index.cgi. > >Is it possible I am missing a perl module? What modules are required? > In case your server is Apache (as I figure from "httpd.conf"), you might want to check your DirectoryIndex tags. In the default configuration there might be DirectoryIndex index.html and you want to add there DirectoryIndex index.html index.cgi For more information concerning the directive consult Apache documentation, e.g. http://httpd.apache.org/docs/mod/mod_dir.html#directoryindex r. Matti L |
From: Wrenn, B. J. <Bobby.Wrenn@BancTec.com> - 2003-09-30 21:30:57
|
After following the brief install instructions and adding index.cgi as a default web page in httpd.conf, I get the source listing when I try to view cms/index.cgi. Is it possible I am missing a perl module? What modules are required? TIA Bobby Wrenn Logistics Planner BancTec, Inc |
From: Alexandre G. <gr...@in...> - 2002-02-23 22:21:21
|
Hi Roger, I've just taken a look at your installation of CMS. I must say I like the ability of haveing a file being auto-reserved when uploaded. I'll soon add a configuration option to have that (or not). I will also look into implementing a .readonly flag on files that could be set by an admin or the owner of the file (implies a .owner file). As far as RCS goes, I have a couple ideas on a version control system for CMS. Since most of the files stored on a typical CMS installation will (IMHO) be binary files and not text files, I don't currently have plans to use a VCS that has the diffs/patches functionnalities. There would be a simple way of implementing it without third-party software (thus still keeping an out-of-the-box complete functionnality of CMS). To try and explain it, the idea would be that, when a file is uploaded (or shall we say updated), the current file is renames to: thefile.doc.<date-of-the-previous-file-in-seconds-elapsed-since-1970-or- something-like-that>.v This way, it is very easy to list all the version of a given file up to the current one, with dates at which each was checked-in. A separate window could list those, and also allowing an admin to delete previous versions to free up some space. In the meantime, feel free to test the CVS version and report the bugs you come accross as we near a stable release version. Alexandre Gravel Infivia Solutions gr...@in... http://www.infivia.com //solutions internet //d=E9veloppement web //h=E9bergement = //consultation =20 > -----Original Message----- > From: cms...@li...=20 > [mailto:cms...@li...] On Behalf Of Roger Buck > Sent: 22 f=E9vrier, 2002 21:20 > To: cms...@li... > Subject: Re: [cms-users] Enhanced CMS 0.02 >=20 >=20 > Alexandre Gravel wrote: > >=20 > > Hi Roger, > >=20 > > We are very well alive and up to work on CMS 0.03. >=20 > Great! >=20 > [--snip--] >=20 > > Roger, feel free to forward me the code you have, even send=20 > it to the=20 > > cms-devel mailing list, join in, we are never enough at working on=20 > > those projects. The more input and suggestions we get, the=20 > better the=20 > > end product can get. >=20 >=20 > OK - Well, I have set up a demo cms and placed a tarball of=20 > the demo site (cms-demo.tgz) there. I'll risk running as-is=20 > for next couple of days in case anyone wants to take a look. >=20 > The changes are mostly cosmetic but might help to explain the=20 > following: >=20 > > 2. How about having a buttton to "reserve" and "unreserve"=20 > files in=20 > > addition to current "checkout" and "available". This would=20 > allow files=20 > > to be better protected. For example, a file could be "reserved" by=20 > > default when uploaded. It would be better still if a file=20 > owner could=20 > > make a file "read only" but the "reserve" option would be=20 > easy to do? >=20 > William McKee wrote: > I'm not sure I understand the need for a reserve function but=20 > haven't implemented CMS in a production environment yet so=20 > may just be overlooking the obvious. At any rate, if this=20 > option is added, it should be optional to have it "reserved"=20 > by default. >=20 > Unless the file is reserved, then any user may (IMHO) too=20 > easily delete. If the file is auto "reseved" on upload, then=20 > this offers some protection against accidental delete? >=20 > Alexandre Gavel wrote: > It would also be pretty to implement the read-only flag=20 > through a thisfile.doc.readonly control file. I'll have to=20 > add that to my wishlist. The thing is though that since we do=20 > not have a definite authentification module, it would hard to=20 > determine who can and who can't set the readonly flag on a=20 > given file. Matti, how about having an admin password and a=20 > user password for the desktops? That could set some flags and=20 > allow more or less options to the user. >=20 >=20 > What I was thinking was that each user should be the=20 > administrator of their own file(s); Whoever first uploads a=20 > file becomes the administrator of that file? Currently I=20 > think this is flagged by using email address? If so, then the=20 > email address is already functioning as a kind of insecure=20 > "password"? Maybe that could be made more secure and be given=20 > extended functionality? >=20 > > 3. Have you thought about using RCS for revision control? I think=20 > > this would be easy to do ( you could take a look at one way that is=20 > > done at http://www.twiki.org/ ). >=20 > William McKee wrote: > Similar opinion here. I like the idea but I don't want to be=20 > forced to use RCS or CVS.=20 >=20 > Understood.... but I think RCS may be OK - I think it is=20 > almost universally distributed and widely used as a "simple",=20 > time saving and robust " plugin"... even the Python FaqWiz=20 > uses it as a plugin... and I doubt they'd have taken that=20 > decision lightly :^) >=20 > William McKee wrote: > Furthermore, there's a serious problem with storing binary=20 > files in CVS, IMHO. CVS (and I presume RCS is the same)=20 > doesn't do diffs between binaries. Thus each time a file is=20 > added, the entire file is added. If you're supporting users=20 > who share large PowerPoint presentations or Word documents,=20 > you're going to eat up some serious diskspace and,=20 > potentially, incur substantial additional storage costs. >=20 > Agreed - I guess I was looking at this as being primarily for=20 > purpose of backup security (as in the sense of a primarily=20 > file distribution - not primarily a devlopment environment). =20 > Wouldn't that require a separate VCS over and above what CMS=20 > is designed to provide? >=20 > Anyhow, I do agree with all your comments and I'm glad you=20 > mentioned storage space issue - is there any intention of=20 > setting simple cms user quotas? >=20 >=20 > You're welcome take a look at a test setup here (I'll place=20 > code there also - see "cms-demo.tgz" ). >=20 http://www.saas.nsw.edu.au/cgi-bin/cms/index.cgi?login=3D1 Demo login details: Folder name: desk1 Password: client1 One other thing while I think of it: Every time a significant change is made, although in general I don't like "push", it would be nice if cms auto-refreshed the client's browser display (say after a new file upload etc)? R. _______________________________________________ cms-users mailing list cms...@li... https://lists.sourceforge.net/lists/listinfo/cms-users |
From: Roger B. <ro...@sa...> - 2002-02-23 04:17:40
|
William McKee wrote: [--snip--] > I like Alexandre idea of preventing deletion by anyone but > the user (or an admin). > > Understood.... but I think RCS may be OK > Except on Win* systems.... Understood... although I think there are some win ports of RCS http://www.cvshome.org/cyclic/cyclic-pages/rcs.html .... but no idea about compatibility with GNU RCS. At best, could be optional. [--snip--] > > Anyhow, I do agree with all your comments and I'm glad you > > mentioned storage space issue - is there any intention of > > setting simple cms user quotas? > > That's an interesting idea of setting quotas but not quite > what my concern was about. Let me know if I've confused you. I don't think you confused me - more that I moved slightly off topic... In prev msg you said: "If you're supporting users who share large PowerPoint presentations or Word documents, you're going to eat up some serious diskspace and, potentially, incur substantial additional storage costs." I think you were refering to storage space costs associated with multiple backup copies versus diffs? ...but I went off at a tangent; Your comments reminded me that currently, any user may keep uploading until they fill all available space on the disk. Is that correct understanding? R. PS I've just discovered and DL'd 0.30-branch and can see some of my earlier comments are redundant :-) |
From: Roger B. <ro...@sa...> - 2002-02-23 02:20:08
|
Alexandre Gravel wrote: > > Hi Roger, > > We are very well alive and up to work on CMS 0.03. Great! [--snip--] > Roger, feel free to forward me the code you have, even send it to the > cms-devel mailing list, join in, we are never enough at working on those > projects. The more input and suggestions we get, the better the end > product can get. OK - Well, I have set up a demo cms and placed a tarball of the demo site (cms-demo.tgz) there. I'll risk running as-is for next couple of days in case anyone wants to take a look. The changes are mostly cosmetic but might help to explain the following: > 2. How about having a buttton to "reserve" and "unreserve" files in > addition to current "checkout" and "available". This would allow files > to be better protected. For example, a file could be "reserved" by > default when uploaded. It would be better still if a file owner could > make a file "read only" but the "reserve" option would be easy to do? William McKee wrote: I'm not sure I understand the need for a reserve function but haven't implemented CMS in a production environment yet so may just be overlooking the obvious. At any rate, if this option is added, it should be optional to have it "reserved" by default. Unless the file is reserved, then any user may (IMHO) too easily delete. If the file is auto "reseved" on upload, then this offers some protection against accidental delete? Alexandre Gavel wrote: It would also be pretty to implement the read-only flag through a thisfile.doc.readonly control file. I'll have to add that to my wishlist. The thing is though that since we do not have a definite authentification module, it would hard to determine who can and who can't set the readonly flag on a given file. Matti, how about having an admin password and a user password for the desktops? That could set some flags and allow more or less options to the user. What I was thinking was that each user should be the administrator of their own file(s); Whoever first uploads a file becomes the administrator of that file? Currently I think this is flagged by using email address? If so, then the email address is already functioning as a kind of insecure "password"? Maybe that could be made more secure and be given extended functionality? > 3. Have you thought about using RCS for revision control? I think this > would be easy to do ( you could take a look at one way that is done at > http://www.twiki.org/ ). William McKee wrote: Similar opinion here. I like the idea but I don't want to be forced to use RCS or CVS. Understood.... but I think RCS may be OK - I think it is almost universally distributed and widely used as a "simple", time saving and robust " plugin"... even the Python FaqWiz uses it as a plugin... and I doubt they'd have taken that decision lightly :^) William McKee wrote: Furthermore, there's a serious problem with storing binary files in CVS, IMHO. CVS (and I presume RCS is the same) doesn't do diffs between binaries. Thus each time a file is added, the entire file is added. If you're supporting users who share large PowerPoint presentations or Word documents, you're going to eat up some serious diskspace and, potentially, incur substantial additional storage costs. Agreed - I guess I was looking at this as being primarily for purpose of backup security (as in the sense of a primarily file distribution - not primarily a devlopment environment). Wouldn't that require a separate VCS over and above what CMS is designed to provide? Anyhow, I do agree with all your comments and I'm glad you mentioned storage space issue - is there any intention of setting simple cms user quotas? You're welcome take a look at a test setup here (I'll place code there also - see "cms-demo.tgz" ). http://www.saas.nsw.edu.au/cgi-bin/cms/index.cgi?login=1 Demo login details: Folder name: desk1 Password: client1 One other thing while I think of it: Every time a significant change is made, although in general I don't like "push", it would be nice if cms auto-refreshed the client's browser display (say after a new file upload etc)? R. |
From: Alexandre G. <gr...@in...> - 2002-02-22 15:02:22
|
Hi Roger, We are very well alive and up to work on CMS 0.03. We have had a couple improvements for 0.03 in the past weeks as we try our best to have a stable release to put out. The comments and suggestions you posted are very interesting. Having dot files for the control files is very interesting. It would indeed make for cleaner directory listings from Samba and ftp, but my questions is, if you have a CMS installation, one should not access those files through Samba or FTP as it might break the reserved/comments/etc state. But I admit that putting the control files as dotfiles will detach them from the real content, an definite improvement. It would also be pretty to implement the read-only flag through a thisfile.doc.readonly control file. I'll have to add that to my wishlist. The thing is though that since we do not have a definite authentification module, it would hard to determine who can and who can't set the readonly flag on a given file. Matti, how about having an admin password and a user password for the desktops? That could set some flags and allow more or less options to the user. As for RCS, I've taken a look at it, and it could be mighty interesting. It would have to be implemented as an option though as I want CMS to work out-of-the-box without anything installed, but with eventually many additional options that one can enable or not. Same goes for the FTP download options. It all depends on the local system on which it is installed. Roger, feel free to forward me the code you have, even send it to the cms-devel mailing list, join in, we are never enough at working on those projects. The more input and suggestions we get, the better the end product can get. Take care and thanks ! Alexandre Gravel Infivia Solutions gr...@in... http://www.infivia.com //solutions internet //d=E9veloppement web //h=E9bergement = //consultation =20 > -----Original Message----- > From: cms...@li...=20 > [mailto:cms...@li...] On Behalf Of Roger Buck > Sent: 22 f=E9vrier, 2002 01:06 > To: Matti Lattu > Cc: cms...@li... > Subject: Re: [cms-users] Enhanced CMS 0.02 >=20 >=20 > Hi Matti (and Alexandre?) >=20 > A long time ago, Matti Lattu wrote: > >=20 > > Hi! > >=20 > > I have worked few weekends with CMS making some=20 > enhancements which me=20 > > and my colleagues need for our groupware. >=20 > I have spent a few hours playing with this - the changes are=20 > excellent, thanks! >=20 > Please let me know if you have done any more development on=20 > this as I'd be keen to take a look. >=20 > Some comments about 0.02-E1 >=20 > 1. Is it worth having an option to save the *comment and=20 > *note files as "dot files" (for example: .somefile.note=20 > instead of somefile.note)? The reason is: If the cms folders=20 > are shared by Samba or FTP users, the dot files are not=20 > listed - This means a cleaner index option for when when=20 > using FTP or Samba. >=20 > 2. How about having a buttton to "reserve" and "unreserve"=20 > files in addition to current "checkout" and "available". This=20 > would allow files to be better protected. For example, a file=20 > could be "reserved" by default when uploaded. It would be=20 > better still if a file owner could make a file "read only"=20 > but the "reserve" option would be easy to do? >=20 > 3. Have you thought about using RCS for revision control? I=20 > think this would be easy to do ( you could take a look at one=20 > way that is done at http://www.twiki.org/ ). >=20 > 4. I have run into a few download problems (mostly javascript=20 > errors) with unusual browser versions. Maybe an ftp download=20 > option in addition to current options might be useful? >=20 > I have modified (badly) cms-0.02-E1 to do some of the above=20 > but I am a useless coder so not offering them as a patch...=20 > but let me know if you are interested in taking a look at the=20 > changes - they at least provide a hands on example of what I=20 > am talking about above. I would not be able to do any coding=20 > but happy to help with testing and documentation if anyone is=20 > interested in doing anything on this. > =20 >=20 > Thanks Matti (and thanks also to Alexandre for original cms), >=20 > R. >=20 > (PS I am sending copy to list and to personal as I am unsure=20 > if there is any "life " in the list ;^) >=20 > > + Possibiliy for multiple desktops (parallel shared filesystems)=20 > > + Desktops are password-protected (MD5-hashed cooke used)=20 > Note window=20 > > + for longer file/directory -related text. Intended for > > commenting, discussion etc. > > + Option to download the files using browser's right-click popup and > > SaveAs ("manual download"). I've had problems with IEs too eagerly=20 > > executing helpers with messy outcomes. > > + File uploading works now also under IIS 5.0 > > + Enhanced security features: All CGI parameters are=20 > filtered, upload > > through separate program > >=20 > > If you're interested to try it, the current release=20 > (0.02-E1) can be=20 > > downloaded from http://www.dogman.fi/software. Alexandre=20 > Gravel, the=20 > > author of CMS, has not replied my offer to participate "officially"=20 > > the CMS project so I'm bit unsure about the future of my=20 > version. Any=20 > > suggestions to how I should proceed? > >=20 > > r. Matti > >=20 > > _______________________________________________ > > cms-users mailing list > > cms...@li...=20 > > https://lists.sourceforge.net/lists/listinfo/cms-users >=20 > _______________________________________________ > cms-users mailing list > cms...@li...=20 > https://lists.sourceforge.net/lists/listinfo/c> ms-users >=20 |
From: Roger B. <ro...@sa...> - 2002-02-22 06:05:59
|
Hi Matti (and Alexandre?) A long time ago, Matti Lattu wrote: > > Hi! > > I have worked few weekends with CMS making some enhancements which me > and my colleagues need for our groupware. I have spent a few hours playing with this - the changes are excellent, thanks! Please let me know if you have done any more development on this as I'd be keen to take a look. Some comments about 0.02-E1 1. Is it worth having an option to save the *comment and *note files as "dot files" (for example: .somefile.note instead of somefile.note)? The reason is: If the cms folders are shared by Samba or FTP users, the dot files are not listed - This means a cleaner index option for when when using FTP or Samba. 2. How about having a buttton to "reserve" and "unreserve" files in addition to current "checkout" and "available". This would allow files to be better protected. For example, a file could be "reserved" by default when uploaded. It would be better still if a file owner could make a file "read only" but the "reserve" option would be easy to do? 3. Have you thought about using RCS for revision control? I think this would be easy to do ( you could take a look at one way that is done at http://www.twiki.org/ ). 4. I have run into a few download problems (mostly javascript errors) with unusual browser versions. Maybe an ftp download option in addition to current options might be useful? I have modified (badly) cms-0.02-E1 to do some of the above but I am a useless coder so not offering them as a patch... but let me know if you are interested in taking a look at the changes - they at least provide a hands on example of what I am talking about above. I would not be able to do any coding but happy to help with testing and documentation if anyone is interested in doing anything on this. Thanks Matti (and thanks also to Alexandre for original cms), R. (PS I am sending copy to list and to personal as I am unsure if there is any "life " in the list ;^) > + Possibiliy for multiple desktops (parallel shared filesystems) > + Desktops are password-protected (MD5-hashed cooke used) > + Note window for longer file/directory -related text. Intended for > commenting, discussion etc. > + Option to download the files using browser's right-click popup and > SaveAs ("manual download"). I've had problems with IEs too eagerly > executing helpers with messy outcomes. > + File uploading works now also under IIS 5.0 > + Enhanced security features: All CGI parameters are filtered, upload > through separate program > > If you're interested to try it, the current release (0.02-E1) can be > downloaded from http://www.dogman.fi/software. Alexandre Gravel, the > author of CMS, has not replied my offer to participate "officially" the > CMS project so I'm bit unsure about the future of my version. Any > suggestions to how I should proceed? > > r. Matti > > _______________________________________________ > cms-users mailing list > cms...@li... > https://lists.sourceforge.net/lists/listinfo/cms-users |
From: Matti L. <mat...@he...> - 2002-01-26 18:29:01
|
Hi! I have worked few weekends with CMS making some enhancements which me and my colleagues need for our groupware. + Possibiliy for multiple desktops (parallel shared filesystems) + Desktops are password-protected (MD5-hashed cooke used) + Note window for longer file/directory -related text. Intended for commenting, discussion etc. + Option to download the files using browser's right-click popup and SaveAs ("manual download"). I've had problems with IEs too eagerly executing helpers with messy outcomes. + File uploading works now also under IIS 5.0 + Enhanced security features: All CGI parameters are filtered, upload through separate program If you're interested to try it, the current release (0.02-E1) can be downloaded from http://www.dogman.fi/software. Alexandre Gravel, the author of CMS, has not replied my offer to participate "officially" the CMS project so I'm bit unsure about the future of my version. Any suggestions to how I should proceed? r. Matti |
From: <npr...@sa...> - 2001-10-08 19:41:52
|
Hello, Every time I do something with cms I am prompted to login. I have cookies enabled. Any other hints??? Thanks Neil |
From: Baldwin S. <ba...@su...> - 2001-10-08 15:37:07
|
When I automatically download a excel file, the browser opens the excel spreadsheet within own window. I do not have any ability to menus. This only happens on Windows. Could you set a option for auto or manual download? Thanks |
From: Baldwin S. <ba...@su...> - 2001-10-08 15:29:15
|
Hi, Great software. Could we add a auto refresh? After I upload or create a new directory, I need to keep clicking on refresh. Thanks |
From: Lynn, M. (DCS) <ML...@ex...> - 2001-09-11 02:25:35
|
Sorry - I should have explained further... I run Linux architecture for Merrill Lynch in New York... we are implementing a Linux Web Hosting environment and have 3 distinct environments in production: Staging, Quality Assurance (Testing), and Production. "Promotion" is the act of moving code from Development into QA or from QA into Staging, or from Staging into Production. I want to use your cms product to extend an interface to my clients. This will give them a view of the code on the individual servers and allow them to "schedule" promotions of the files from one environment to the next on the way to Production. I can tar up what I have so far and send it to you so you can review it. I think it's about 50% there. Right now, it simply creates a <filename>.schedule file in the file system. The format is RECURRINGTYPE:minute:hour:day:month:year. If the Recurring type is either of once, daily, etc. I don't know yet how I will indicate the last promotion that has occurred, perhaps that will be in the same .schedule file - or maybe create a new .schedule_done file or something - thoughts? The remaining work to be done is to code the skulker program that will I must tell you I find the work you've done to be a fantastic peice of work. It is very logically coded - Nice Job! -----Original Message----- From: Alexandre Gravel [mailto:gr...@in...] Sent: Monday, September 10, 2001 3:56 PM To: ml...@ml... Subject: RE: [cms-users] Scheduling Additions anyone? Hiya, What do you mean exactly by "promote" ? And the scheduling, will it be done through crontab or through accesses? Going through the filesystem is an interesting feature. Can you make it so that it can be used for other uses? Like looking for a specific extension (much like .schedule files) and return a hash with path and the content of the given file. I'm sure it could end up being useful in the future. Tell me how your development works out. I'll try and have CVS up soon. Alexandre Gravel gr...@in... Infivia Solutions //solutions internet //developpement web //hebergement //consultation http://www.infivia.com > -----Original Message----- > From: cms...@li... > [mailto:cms...@li...]On Behalf Of Mike Lynn > Sent: 10 septembre, 2001 16:31 > To: cms...@li... > Subject: [cms-users] Scheduling Additions anyone? > > > I have the start of modifications to CMS to support Scheduling files > for promotion (appears as an additional column - next to comments). > When clicked, a new popup appears and asks what type of schedule (once, > hourly, daily, weekly, monthly) and time for promotion. I still need to > complete this peice and to write a skulker that will handle going > through the file system and doing the actual promotions based on the > schedule/time in the <filename>.schedule files. > > Anybody else interested in this - or - have something similar? > > InTHANKSadvance, > Mike > ml...@ml... > > > _______________________________________________ > cms-users mailing list > cms...@li... > https://lists.sourceforge.net/lists/listinfo/cms-users |
From: Mike L. <ml...@ml...> - 2001-09-10 20:33:59
|
I have the start of modifications to CMS to support Scheduling files for promotion (appears as an additional column - next to comments). When clicked, a new popup appears and asks what type of schedule (once, hourly, daily, weekly, monthly) and time for promotion. I still need to complete this peice and to write a skulker that will handle going through the file system and doing the actual promotions based on the schedule/time in the <filename>.schedule files. Anybody else interested in this - or - have something similar? InTHANKSadvance, Mike ml...@ml... |
From: DEVOS B. <bas...@bp...> - 2001-06-15 12:51:22
|
non, mon browser accepte tous les cookies. au d=E9marrage, je m'identifie, ok, je ferme la fen=EAtre Log-in, et = d=E8s que je clique par exemple sur "New Directory", deux fen=EAtres s'ouvrent, une = avec les infos pour la dir =E0 cr=E9er, et une autre avec "Please identify = yourself". M=EAme si je ne ferme pas la premi=E8re fen=EAtre d'ident., il va la = remettre =E0 l'avant-plan avec "please identify yourself" cependant les fonctionnalit=E9s sont op=E9rationnelles. > -----Original Message----- > From: Alexandre Gravel [SMTP:gr...@in...] > Sent: Friday, June 15, 2001 2:44 PM > To: cms...@li... > Subject: RE: [cms-users] Hello >=20 > Hi, >=20 > There isn't a functionnality to remove the identification part from = the > script, but by looking at the code, it should be fairly easy to take = it > out. > The thing is the identification window should not come back every = time. It > should ask you once per session, then store your address in a cookie = and > then not ask you for a while. >=20 > Do you have cookies disabled by any chance ? >=20 > Alexandre Gravel > gr...@in... >=20 > Infivia Solutions > //solutions internet //d=E9veloppement web //h=E9bergement = //consultation > http://www.infivia.com >=20 > > -----Original Message----- > > From: cms...@li... > > [mailto:cms...@li...]On Behalf Of DEVOS = BASTIEN > > Sent: 15 juin, 2001 08:32 > > To: 'cms...@li...' > > Subject: [cms-users] Hello > > > > > > Hi Everybody, > > > > I'm new on this list and I'd like to ask you some things. > > - Is it possible not to use "log-in" feature in CMS ? > > - Is it normal that the window with "Please identify yourself" = comes > back > > every time you refresh your window, or click on a link ? > > > > Identify is not a problem, but the fact it appears everytime = disturbs me > a > > lot. > > > > thanks, > > > > --------------------- > > Bastien Devos > > System A-P, BPO - IT Services Delivery > > bas...@bp... > > > > > > P.S. : How many people are subscribed on this list ? 2, 10 or 200 ? > > > > _______________________________________________ > > cms-users mailing list > > cms...@li... > > http://lists.sourceforge.net/lists/listinfo/cms-users >=20 >=20 > _______________________________________________ > cms-users mailing list > cms...@li... > http://lists.sourceforge.net/lists/listinfo/cms-users |
From: Alexandre G. <gr...@in...> - 2001-06-15 12:44:01
|
Hi, There isn't a functionnality to remove the identification part from the script, but by looking at the code, it should be fairly easy to take it out. The thing is the identification window should not come back every time. It should ask you once per session, then store your address in a cookie and then not ask you for a while. Do you have cookies disabled by any chance ? Alexandre Gravel gr...@in... Infivia Solutions //solutions internet //développement web //hébergement //consultation http://www.infivia.com > -----Original Message----- > From: cms...@li... > [mailto:cms...@li...]On Behalf Of DEVOS BASTIEN > Sent: 15 juin, 2001 08:32 > To: 'cms...@li...' > Subject: [cms-users] Hello > > > Hi Everybody, > > I'm new on this list and I'd like to ask you some things. > - Is it possible not to use "log-in" feature in CMS ? > - Is it normal that the window with "Please identify yourself" comes back > every time you refresh your window, or click on a link ? > > Identify is not a problem, but the fact it appears everytime disturbs me a > lot. > > thanks, > > --------------------- > Bastien Devos > System A-P, BPO - IT Services Delivery > bas...@bp... > > > P.S. : How many people are subscribed on this list ? 2, 10 or 200 ? > > _______________________________________________ > cms-users mailing list > cms...@li... > http://lists.sourceforge.net/lists/listinfo/cms-users |
From: DEVOS B. <bas...@bp...> - 2001-06-15 12:34:04
|
Hi Everybody, I'm new on this list and I'd like to ask you some things. - Is it possible not to use "log-in" feature in CMS ? - Is it normal that the window with "Please identify yourself" comes back every time you refresh your window, or click on a link ? Identify is not a problem, but the fact it appears everytime disturbs me a lot. thanks, --------------------- Bastien Devos System A-P, BPO - IT Services Delivery bas...@bp... P.S. : How many people are subscribed on this list ? 2, 10 or 200 ? |
From: Roger B. <ro...@sa...> - 2000-11-27 05:20:42
|
Hi Alexandre, Alexandre Gravel wrote: > I'm not sure how the API will work yet. Should we work on a temporary > release with the submitted patches or get our heads down to the API-ready > release ? I don't know enough about coding to be much help, so I'll I'll leave the answere to this question to you and\or others > Roger Buck wrote: > > I think there should also be a configurable way to limit the hosts that > > the script can can validly be run from (limit referers). > > That could be easily done with a simple text file that contains the allowed > hosts or disallowed hosts. The check could be done at every execution of the > script. OK - Also see attached code - this was stolen from something I once saw in a script at at http://www.bignosebird.com/ (sorry I can't remember the name of the script). > > Would be nice if the crm generated admin files were kept out of the main > > folder (maybe simply created in a separate, parallel, tree structure - > > this could be done easily using a configurable path variable prefix in > > the crm.cgi? > > By admin files, do you mean the logfile ? No, what I mean is the files currently generated by cms (such as *.comment *.reason and so on..) that are placed in the same folder as the file(s) that cms is designed to manage: What I was thinking of was having two paralell file systems: folder1 is where all the normal userspace file are stored (the current cms variable $filepath) folder2 would be in a separate, paralel tree - say $cmspath.$filepath, where $cmspath is a constat that would be configured by the site admin Does that make any sense? :-) R. Here's the example referer stuff: |
From: Alexandre G. <gr...@so...> - 2000-11-27 03:43:59
|
Hi, I'm not sure how the API will work yet. Should we work on a temporary release with the submitted patches or get our heads down to the API-ready release ? > I am attaching an edited crm.cgi (3 miniscule changes) that will > disallow upload, generates an error message if a file already exists, > and log any attempt to jump to disallowed path. The jump to disallowed path log entry is very interesting. As for the disallowed upload if a file already exists, this is a must for the current 0.02 release. > I think there should also be a configurable way to limit the hosts that > the script can can validly be run from (limit referers). That could be easily done with a simple text file that contains the allowed hosts or disallowed hosts. The check could be done at every execution of the script. > Would be nice if the crm generated admin files were kept out of the main > folder (maybe simply created in a separate, parallel, tree structure - > this could be done easily using a configurable path variable prefix in > the crm.cgi? By admin files, do you mean the logfile ? Alexandre Gravel Infivia Solutions gr...@in... http://www.infivia.com |
From: Roger B. <ro...@sa...> - 2000-11-27 00:34:41
|
I know this cahnge could be done better... but hey, It's something ;^) Search in file for "=========" to find changes I am attaching an edited crm.cgi (3 miniscule changes) that will disallow upload, generates an error message if a file already exists, and log any attempt to jump to disallowed path. I think there should also be a configurable way to limit the hosts that the script can can validly be run from (limit referers). Would be nice if the crm generated admin files were kept out of the main folder (maybe simply created in a separate, parallel, tree structure - this could be done easily using a configurable path variable prefix in the crm.cgi? I noticed the message about coming API stuff but some of above may be worth doing direct in the pl script anyhow. Thanks for a nice project :-) R. |
From: Alexandre G. <gr...@so...> - 2000-11-06 13:58:22
|
Hello, I have started work on building an API for CMS that would allow different modules to be programmed for it. For example, one module could use a SQL database for storage as another could use the local filesystem. The administrator could then decide how to store the content depending on the software available and storage needed. I am thinking about building a basic interface class from which all the modules would be extended. This would use the object-oriented features of Perl and could in the end simplify very much the future development of CMS. Should we make the authentification and storage modules as separate ? I have received emails suggesting the use of the HTTP authentification mechanisms to control access, and I was thinking about building an authentification method based on text and configuration files. What I have to do is to decide how the base classes of the API will be built. Here's what I have in mind: --storageAPI |--setDirectory (sets the current directory) |--getSubdirectories (returns a list of subdirectories in the current directory) |--getFiles (returns a list of files in the current directory) |--getFileProperties (returns the properties of the filename passed in parameter | ie. Reserved or not, comments, date of last modification, etc.) |--checkOut (returns the content of the file passed in parameter. Sets ir reserved | depending on a second parameter) |--checkIn (takes the filename and its content by parameter) |--discardReservation (discards the reservation on a filename passed in parameter) |--setComment (sets a comment on a filename, both passed in parameter) |--createDirectory (creates a new subdirectory in the current directory) |--deleteFile (deletes a file) --authentificationAPI |--login (takes a username and password in parameter and returns wether it was | successfull or not) |--logout (logs out a given user) Now, this API would allow us to have one main file where calls are made to the right API depending on the configuration selected. Any comments, suggestions ? Alexandre Gravel Infivia Solutions gr...@in... http://www.infivia.com |
From: Tim L. <tim...@do...> - 2000-10-17 00:03:49
|
- Some sort of authentication. - Non-web accessible directory with files. - Remove directories and files in the directories. - Removing the need to refresh after login or changes made. - Group access to only certain files and directories for certain users (user can be in one or many groups). - Support for uploading to directories with spaces. - Can't overwrite an existing file. - Can't create a directory when it already exists. - Maybe store details in MySQL database. Most important to me is the authentication and overwriting on existing/reserved files. Regards Tim Lock Mobile: +614 1713 0684 dotWAP Holdings Pty. Ltd. http://www.dotWAP.com |
From: Alexandre G. <gr...@ca...> - 2000-10-13 17:08:32
|
Mark, Yes indeed, it is very insecure to have them currently in available through http. The next release is sure to fix that. All I have to find is a way to push easily the data to the user, using a MIME type that will have it saved to disk (since currently if you check-out a gif file, it will simply show up in the window). Alexandre Gravel SoundSpeed Movie Database gr...@so... http://www.soundspeedmovie.com |
From: Alexandre G. <gr...@so...> - 2000-10-13 16:51:16
|
Mark, Yes indeed, it is very insecure to have them currently in available through http. The next release is sure to fix that. All I have to find is a way to push easily the data to the user, using a MIME type that will have it saved to disk (since currently if you check-out a gif file, it will simply show up in the window). Alexandre Gravel SoundSpeed Movie Database gr...@so... http://www.soundspeedmovie.com |
From: Nold, M. <Mar...@no...> - 2000-10-13 03:43:50
|
---------------------------------------------------------------------------- ----------------- Disclaimer: The information contained in this email is intended only for the use of the person(s) to whom it is addressed and may be confidential or contain legally privileged information. If you are not the intended recipient you are hereby notified that any perusal, use, distribution, copying or disclosure is strictly prohibited. If you have received this email in error please immediately advise us by return email at pos...@no... and delete the email document without making a copy. ---------------------------------------------------------------------------- ----------------- CMS looks interesting but i wonder if making documents available in the web root via http://cms.sourceforge.net/content/nondivul.pdf <http://cms.sourceforge.net/content/nondivul.pdf> is the best idea? Typically you'd want to put these documents out of the document root so you can secure them. mn Mark Nold ma...@al... Systems Consultant Change is inevitable, except from vending machines. |