Menu
▾
▴
phpicalendar-devel — Mailing list for PHP iCalendar Developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(159) |
Nov
(123) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(11) |
Mar
(21) |
Apr
(29) |
May
(13) |
Jun
(2) |
Jul
(13) |
Aug
(5) |
Sep
(14) |
Oct
(21) |
Nov
(71) |
Dec
|
| 2004 |
Jan
(18) |
Feb
(12) |
Mar
|
Apr
(6) |
May
(29) |
Jun
(9) |
Jul
(3) |
Aug
(4) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(20) |
| 2005 |
Jan
(6) |
Feb
(27) |
Mar
(4) |
Apr
(16) |
May
(61) |
Jun
(6) |
Jul
(4) |
Aug
(18) |
Sep
(19) |
Oct
(5) |
Nov
(55) |
Dec
(30) |
| 2006 |
Jan
(11) |
Feb
(9) |
Mar
(9) |
Apr
(26) |
May
(17) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(20) |
Oct
|
Nov
(6) |
Dec
(9) |
| 2007 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(8) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(17) |
Mar
(11) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chad <ch...@ch...> - 2003-04-03 17:45:27
|
But when dragging something to the trash, lets say from the network drive, its your only out (the dialog box). In our situation the user is already logging in, manually picking a checkbox, then thirdly clicking delete. If 99.9% of them at that point click yes, whats the point to having it? We're not protecting anyone and we're just adding confusing code to the config and bloating out the project. -C On Thursday, April 3, 2003, at 08:55 AM, Marook Zuug Kenja wrote: > Ups: Apple's HIG specify that any function that delete data that can > not be undone, should show an alert to the user, no matter who the > user it. It does state, though, the the user might have a preference > to turn off those alerts. > So, the implementation done here, is, by definition, state-of-the-art. |
|
From: Marook Z. K. <ma...@cr...> - 2003-04-03 16:56:49
|
Hi. On onsdag, apr 2, 2003, at 10:36 Europe/Copenhagen, Chad wrote: > Please respond to this email if you plan on 'ever' submitting more=20 > code to the PHP iCalendar project. I do have the plan to do so, but can't see the time coming the next few=20= weeks... Jakob Peterh=E4nsel 'I don't have to try to be a sex bomb, I am one!' - Kylie Minogue Email: ja...@hj... AIM: Marook Phone: +45 40163806 |
|
From: Marook Z. K. <ma...@cr...> - 2003-04-03 16:55:06
|
Hi All. On s=F8ndag, mar 30, 2003, at 19:51 Europe/Copenhagen, Chad wrote: > 1) How about being able to upload more than 1 calendar at a time,=20 > let's try 5. Have a look at Gallery's upload feature (also PHP), it defaults to 5,=20 but have a pop-up to change it from 1 to 10. Very nice. It also have a=20= feature to look in a local directory and then displays all files in it=20= it understand, for the user to select witch ones will get 'uploaded'. http://gallery.sourceforge.net/ > 2) Multiple delete. Let's list all the calendars with unchecked=20 > checkboxs. Whichever get highlighted by the admin get deleted. > 3) Remove the javascript confirm. If Im the admin, I login, select a=20= > calendar, then click delete, I dont need a 4th step to confirm, its=20 > just a waste of time. Ups: Apple's HIG specify that any function that delete data that can=20 not be undone, should show an alert to the user, no matter who the user=20= it. It does state, though, the the user might have a preference to turn=20= off those alerts. So, the implementation done here, is, by definition, state-of-the-art. Jakob Peterh=E4nsel "Tell me why, don't we try, not to break our hearts and make it so hard for our selfs" P.S.B. 1987 Email: ja...@hj... AIM: Marook Phone: +45 40163806 |
|
From: dre <dr...@an...> - 2003-04-03 11:15:48
|
As the time I'm able to invest in this process is sparse - same as for others that responded - I won't be able to contribute a lot. I will though be available to continue to maintain the code for displaying overlapping event and for keeping the german translation updated. - David. -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of Chad Sent: Wednesday, April 02, 2003 10:37 AM To: php...@li... Subject: [PHPiCalendar-DEV] Developer removals Please respond to this email if you plan on 'ever' submitting more code to the PHP iCalendar project. Personally I am tired of working on it. I will see it through to 1.0 but then thats about it. I have other projects I need to work on and I'd like us all to push this to 1.0 so we can 'close' this chapter for the time being. I've appreciated everyone's help over the past 6 months and I hope some of you can dedicate a little bit of time to help hit 1.0. Thanks, Chad ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Phpicalendar-devel mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Brad B. <bbr...@ma...> - 2003-04-02 21:37:11
|
on 4/2/03 1:10 PM, php...@li... at php...@li... wrote: > Please respond to this email if you plan on 'ever' submitting more code > to the PHP iCalendar project. Personally I am tired of working on it. I > will see it through to 1.0 but then thats about it. I have other > projects I need to work on and I'd like us all to push this to 1.0 so > we can 'close' this chapter for the time being. I've appreciated > everyone's help over the past 6 months and I hope some of you can > dedicate a little bit of time to help hit 1.0. > > Thanks, > Chad I don't know what or when we can contribute, but on of our projects on the near-horizon is planning on using this. I'm sure we'd be modifying (and possibly contributing the code, if it's not special-purpose), so I guess that qualifies as "ever". :-) Nothing substantive is likely to happen on that front for a couple more months, though, because of other projects that have to get finished first. -brad -- Brad Brighton, Co-Founder bbr...@ma... MacEdition http://www.macedition.com |
|
From: Cory B. <pi...@hi...> - 2003-04-02 17:56:59
|
I am interested in contributing to the project at some point. Right now I'm very swamped with work, but I will most certainly contribute at some point. -Cory On Wed, 2003-04-02 at 10:47, Bill Fenner wrote: > I'd like to finish up and tweak the email event stuff. > > Bill > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > -- Cory Bertsch <pi...@hi...> |
|
From: Bill F. <fe...@re...> - 2003-04-02 17:47:18
|
I'd like to finish up and tweak the email event stuff. Bill |
|
From: Greg W. <gr...@gr...> - 2003-04-02 16:45:12
|
I plan to continue to work on the project, though I haven't done much=20 recently. Frankly, I'm hoping that Apple will just take the plunge and=20= let us properly share calendars and edit them from multiple computers. =20= But even then, I'll need something like PHP iCalendar to see my=20 calendars from the road and such. So I want to see the project through=20= at least to a stage where we can view multiple calendars at once, it=20 properly displays my calendars, etc. Lately I've noticed that PHP=20 iCalendar doesn't seem to handle some things like changed events right=20= all the time. I don't have much interest in adding features after=20 multiple calendar support, but I'd like to work on troubleshooting,=20 improving the interface, etc. Greg On Wednesday, April 2, 2003, at 09:29 AM, Mike Traum wrote: > I don't know if this is only directed to developers, but I plan on=20 > helping out with some bug fixes. If all submitters are gone, how will=20= > this be accomplished? > > mike > > =A0Chad <ch...@ch...> wrote: > > Please respond to this email if you plan on 'ever' submitting more = code > to the PHP iCalendar project. Personally I am tired of working on it. = I > will see it through to 1.0 but then thats about it. I have other > projects I need to work on and I'd like us all to push this to 1.0 so > we can 'close' this chapter for the time being. I've appreciated > everyone's help over the past 6 months and I hope some of you can > dedicate a little bit of time to help hit 1.0. > > Thanks, > Chad > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > <image.tiff> > > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more -- http://www.gregwestin.com Contact info: http://www.gregwestin.com/contact.php |
|
From: Mike T. <mt...@ya...> - 2003-04-02 14:30:02
|
I don't know if this is only directed to developers, but I plan on helping out with some bug fixes. If all submitters are gone, how will this be accomplished? mike Chad <ch...@ch...> wrote:Please respond to this email if you plan on 'ever' submitting more code to the PHP iCalendar project. Personally I am tired of working on it. I will see it through to 1.0 but then thats about it. I have other projects I need to work on and I'd like us all to push this to 1.0 so we can 'close' this chapter for the time being. I've appreciated everyone's help over the past 6 months and I hope some of you can dedicate a little bit of time to help hit 1.0. Thanks, Chad ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Phpicalendar-devel mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more |
|
From: Chad <ch...@ch...> - 2003-04-02 08:37:15
|
Please respond to this email if you plan on 'ever' submitting more code to the PHP iCalendar project. Personally I am tired of working on it. I will see it through to 1.0 but then thats about it. I have other projects I need to work on and I'd like us all to push this to 1.0 so we can 'close' this chapter for the time being. I've appreciated everyone's help over the past 6 months and I hope some of you can dedicate a little bit of time to help hit 1.0. Thanks, Chad |
|
From: Chad <ch...@ch...> - 2003-03-31 17:29:30
|
Thats not a goal of the project anytime soon. On Sunday, March 30, 2003, at 11:44 PM, JM Alonzo wrote: > > hi, > > are you guys planning to put up db support for phpicalendar? > > thanks a lot. > > -- > .''`. JM Alonzo "We are each entitled to our own > : :' : jmalonzo-at-spaceants.org opinion, but no one is entitled > `. `' to his own facts." > `- <http://spaceants.org> -- Patrick Moynihan > > <mime-attachment> |
|
From: JM A. <jma...@sp...> - 2003-03-31 07:45:19
|
hi,=20 are you guys planning to put up db support for phpicalendar? thanks a lot. --=20 .''`. JM Alonzo "We are each entitled to our own=20 : :' : jmalonzo-at-spaceants.org opinion, but no one is entitled=20 `. `' to his own facts." `- <http://spaceants.org> -- Patrick Moynihan |
|
From: Greg W. <gr...@gr...> - 2003-03-30 19:04:59
|
> Re 3 - this can be disabled in the with the config.ini.php variable,=20= > but I can remove it altogether if there's something you really dislike=20= > about the way it's implemented. The only reservation I have is the=20 > user who, later on, really want this type of functionality. I agree with the attempt to move away from Javascript, and doubt that=20 this functionality would ever be that necessary, but I guess it's not a=20= big deal if we ship with the config variable defaulting to no. > Re=A04 - It shouldn't be that much of a problem for them to be in=20 > config.inc.php. Admins who are concerned could just use=A0http basic = or=20 > digest and disable the config.inc.php username/pass. The point of the=20= > internal authentication was so be a simple & open, but not 100% secure=20= > method of authentication. If you require http basic, ftp, webdav, it's=20= > no longer general. For example, I've used a number of servers that do=20= > not have either ftp or webdav, but rely on ssh (which is encrypted). I=20= > think this is a good feature to have, and believe that as long as we=20= > highlight the caveats in the docs, people would benefit from it=20 > staying. Why would someone who relies on ssh want to use such an insecure form=20 of authentication? If you've got a server that doesn't allow any=20 webdav or ftp access, I doubt they're going to want to allow this sort=20= of thing. I guess it's possible, but is it a reasonable enough=20 scenario to cater to it? Again, it doesn't seem to be a big deal to=20 have the option, except in that the config.ini.php file just gets=20 longer and more trouble to configure (and, there's no point to having=20 features that won't be used and which take up space). That's all I got. Greg -- http://www.gregwestin.com Contact info: http://www.gregwestin.com/contact.php |
|
From: Mike T. <mt...@ya...> - 2003-03-30 18:26:25
|
Re 1 & 2 - sounds good - I'll start with this. Re 3 - this can be disabled in the with the config.ini.php variable, but I can remove it altogether if there's something you really dislike about the way it's implemented. The only reservation I have is the user who, later on, really want this type of functionality. Re 4 - It shouldn't be that much of a problem for them to be in config.inc.php. Admins who are concerned could just use http basic or digest and disable the config.inc.php username/pass. The point of the internal authentication was so be a simple & open, but not 100% secure method of authentication. If you require http basic, ftp, webdav, it's no longer general. For example, I've used a number of servers that do not have either ftp or webdav, but rely on ssh (which is encrypted). I think this is a good feature to have, and believe that as long as we highlight the caveats in the docs, people would benefit from it staying. Re 5 - The cookie is used to store state information, meaning that once they login, we need to know that. If we don't use a cookie, we have to carry the password from page to page using form parameters. This isn't more secure, and just a sloppier way to handle things. Re 6 - I think the unlink just needs to be converted to a function call which will handle more cases. unlink() is a very standard function, but there are many different system configs which need to be taken into account. I'll look into this. Regarding your system, I suspect that your webserver is running as a user which doesn't have rights to delete files created by the user you are creating files with. afaik, this is not the normal configuration. Re 7 - I agree. But, there always that line you walk between reducing your translation needs, and having a user friendly app. Being that this is an admin portion, I don't think it would be unacceptable to have it in english-only until translations start rolling in from users. Comments? thanks, mike Chad <ch...@ch...> wrote:Some more thoughts: 1) How about being able to upload more than 1 calendar at a time, let's try 5. 2) Multiple delete. Let's list all the calendars with unchecked checkboxs. Whichever get highlighted by the admin get deleted. 3) Remove the javascript confirm. If Im the admin, I login, select a calendar, then click delete, I dont need a 4th step to confirm, its just a waste of time. 4) Username and passwords will not be stored in the config. I don't want them set anywhere where someone else could get access. Anyone using PHP iCalendar has some sort of ftp or webdav username and password already on the system. Use them. 5) Cookies. Not sure what to do here. Personally I don't think we should set a cookie, since its an added security risk. I don't think people will be loging in daily to admin their calendars, if they are they need a better solution than the admin page. 6) Unlink. Seems like another possible security problem. If ftp is more supported, than why not use it. Unlink requires no username and password. Would like to hear from other developers on this one. That and it doesn't work on my development machine (Mac OS X). 6) Translations. Seems like we have a good bit of new lines, perhaps we can look at this and lighten them up a bit. Please don't get discouraged by this list. Your contribution is greatly appreciated and will help make PHP iCalendar better. I just need to think about things overall -- Ease of use, Setup, Security, Looks, Functionality -- and work with all the developers (I know they are here somewhere) to find a common ground. Thanks. C On Saturday, March 29, 2003, at 05:31 PM, Mike Traum wrote: > Re: unlink error, I don't get that error on my server - maybe a server > config issue? This may be a better way to delete (from php.net): > > function suppr($file) { > $delete = @unlink($file); > if (@file_exists($file)) { > $filesys = eregi_replace("/","\\",$file); > $delete = @system("del $filesys"); > if (@file_exists($file)) { > $delete = @chmod ($file, 0775); > $delete = @unlink($file); > $delete = @system("del $filesys");}}} > ?> > > Re: javascript confirm, it can de disabled by setting $confirm_changes > to 'no' in config.inc.php, so I don't know why it needs be removed. > > Re: coding standards, I thought I was. Which part didn't meet your > standards? > > mike > > Chad wrote: > > Well, it need a bit of a polish, which I can take care of over the next > few days. I also got an error trying to delete a calendar: > > Warning : unlink() failed (Permission denied) in > /Users/clittle/Sites/phpicalendar/admin.php on line 180. > > The coding standards should also match ours, so developers can expect > consistant structure. The javascript confim can also go away. I've > committed it for now but we'll have to work it over. > > -C > > On Friday, March 28, 2003, at 12:55 PM, Mike Traum wrote: > > > Thanks for all of the good suggestions regarding the admin control > > panel. The patch is available on the sourceforge patch page. Please > > help by testing this so we can get it up to release standards asap. > > > > thanks, > > mike > > > > > > > > > > > Do you Yahoo!? > > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your > desktop! > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > > > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: Chad <ch...@ch...> - 2003-03-30 17:51:58
|
Some more thoughts: 1) How about being able to upload more than 1 calendar at a time, let's=20= try 5. 2) Multiple delete. Let's list all the calendars with unchecked=20 checkboxs. Whichever get highlighted by the admin get deleted. 3) Remove the javascript confirm. If Im the admin, I login, select a=20 calendar, then click delete, I dont need a 4th step to confirm, its=20 just a waste of time. 4) Username and passwords will not be stored in the config. I don't=20 want them set anywhere where someone else could get access. Anyone=20 using PHP iCalendar has some sort of ftp or webdav username and=20 password already on the system. Use them. 5) Cookies. Not sure what to do here. Personally I don't think we=20 should set a cookie, since its an added security risk. I don't think=20 people will be loging in daily to admin their calendars, if they are=20 they need a better solution than the admin page. 6) Unlink. Seems like another possible security problem. If ftp is more=20= supported, than why not use it. Unlink requires no username and=20 password. Would like to hear from other developers on this one. That=20 and it doesn't work on my development machine (Mac OS X). 6) Translations. Seems like we have a good bit of new lines, perhaps we=20= can look at this and lighten them up a bit. Please don't get discouraged by this list. Your contribution is greatly=20= appreciated and will help make PHP iCalendar better. I just need to=20 think about things overall -- Ease of use, Setup, Security, Looks,=20 Functionality -- and work with all the developers (I know they are here=20= somewhere) to find a common ground. Thanks. C On Saturday, March 29, 2003, at 05:31 PM, Mike Traum wrote: > Re: unlink error, I don't get that error on my server - maybe a server=20= > config issue? This may be a better way to delete (from php.net): > <?php > function suppr($file) { > $delete =3D @unlink($file); > if (@file_exists($file)) { > $filesys =3D eregi_replace("/","\\",$file); > $delete =3D @system("del $filesys"); > if (@file_exists($file)) { > $delete =3D @chmod ($file, 0775); > $delete =3D @unlink($file); > $delete =3D @system("del $filesys");}}} > ?> > > Re: javascript confirm, it can de disabled by setting $confirm_changes=20= > to 'no' in config.inc.php, so I don't know why it needs be removed. > > Re: coding standards, I thought I was. Which part didn't meet your=20 > standards? > > mike > > =A0Chad <ch...@ch...> wrote: > > Well, it need a bit of a polish, which I can take care of over the = next > few days. I also got an error trying to delete a calendar: > > Warning : unlink() failed (Permission denied) in > /Users/clittle/Sites/phpicalendar/admin.php on line 180. > > The coding standards should also match ours, so developers can expect > consistant structure. The javascript confim can also go away. I've > committed it for now but we'll have to work it over. > > -C > > On Friday, March 28, 2003, at 12:55 PM, Mike Traum wrote: > > > Thanks for all of the good suggestions regarding the admin control > > panel. The patch is available on the sourceforge patch page. Please > > help by testing this so=A0we can get it up to release standards = asap. > > > > thanks, > > mike > > > > > > > > > > > Do you Yahoo!? > > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your=20 > desktop! > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > > <image.tiff> > > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!= |
|
From: Mike T. <mt...@ya...> - 2003-03-30 01:31:47
|
Re: unlink error, I don't get that error on my server - maybe a server config issue? This may be a better way to delete (from php.net): <?php function suppr($file) { $delete = @unlink($file); if (@file_exists($file)) { $filesys = eregi_replace("/","\\",$file); $delete = @system("del $filesys"); if (@file_exists($file)) { $delete = @chmod ($file, 0775); $delete = @unlink($file); $delete = @system("del $filesys");}}} ?> Re: javascript confirm, it can de disabled by setting $confirm_changes to 'no' in config.inc.php, so I don't know why it needs be removed. Re: coding standards, I thought I was. Which part didn't meet your standards? mike Chad <ch...@ch...> wrote:Well, it need a bit of a polish, which I can take care of over the next few days. I also got an error trying to delete a calendar: Warning : unlink() failed (Permission denied) in /Users/clittle/Sites/phpicalendar/admin.php on line 180. The coding standards should also match ours, so developers can expect consistant structure. The javascript confim can also go away. I've committed it for now but we'll have to work it over. -C On Friday, March 28, 2003, at 12:55 PM, Mike Traum wrote: > Thanks for all of the good suggestions regarding the admin control > panel. The patch is available on the sourceforge patch page. Please > help by testing this so we can get it up to release standards asap. > > thanks, > mike > > > > > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Phpicalendar-devel mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: Chad <ch...@ch...> - 2003-03-30 00:31:28
|
Well, it need a bit of a polish, which I can take care of over the next=20= few days. I also got an error trying to delete a calendar: Warning : unlink() failed (Permission denied) in=20 /Users/clittle/Sites/phpicalendar/admin.php on line 180. The coding standards should also match ours, so developers can expect=20 consistant structure. The javascript confim can also go away. I've=20 committed it for now but we'll have to work it over. -C On Friday, March 28, 2003, at 12:55 PM, Mike Traum wrote: > Thanks for all of the good suggestions regarding the admin control=20 > panel. The patch is available on the sourceforge patch page. Please=20 > help by testing this so=A0we can get it up to release standards asap. > > thanks, > mike > > > <image.tiff> > > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!= |
|
From: Mike T. <mt...@ya...> - 2003-03-28 20:56:01
|
Thanks for all of the good suggestions regarding the admin control panel. The patch is available on the sourceforge patch page. Please help by testing this so we can get it up to release standards asap. thanks, mike --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: Greg W. <gr...@gr...> - 2003-03-28 20:53:13
|
I don't know of any reason why digest authentication would need to be handled differently from basic, but because everyone was using the word digest, rather than calling it something more general, I thought I'd throw that out there. Just disregard it if it doesn't apply. Greg --- http://www.gregwestin.com/ Contact info: http://www.gregwestin.com/contact.php On Fri, 28 Mar 2003, blaine wrote: > On Friday, Mar 28, 2003, at 10:54 America/Vancouver, Greg Westin wrote: > > > If the digest option is used, it definitely needs to be an option... > > keep > > in mind that many people are still using basic authentication, for > > whatever reason. > > I'm a bit confused on this point; I hope the proposed method wasn't to > actually re-implement digest auth! ;-) As long as just the > $REMOTE_USER environment variable is used, then both digest and basic > should work fine (plus any other methods, like auth tokens, etc.). Am I > somehow mistaken, or is "digest" just being misused? > > b. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > |
|
From: Mike T. <mt...@ya...> - 2003-03-28 19:46:28
|
Right now, I have a config variable to turn off the authentican alltogether, which would allow you to use http authentication. I'm not checking $REMOTE_USER. The use of that, I suppose, would be to allow certain users and disallow others. But, that could be setup in .htaccess, couldn't it? mike blaine <la...@us...> wrote:On Friday, Mar 28, 2003, at 10:54 America/Vancouver, Greg Westin wrote: > If the digest option is used, it definitely needs to be an option... > keep > in mind that many people are still using basic authentication, for > whatever reason. I'm a bit confused on this point; I hope the proposed method wasn't to actually re-implement digest auth! ;-) As long as just the $REMOTE_USER environment variable is used, then both digest and basic should work fine (plus any other methods, like auth tokens, etc.). Am I somehow mistaken, or is "digest" just being misused? b. ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Phpicalendar-devel mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: blaine <la...@us...> - 2003-03-28 19:09:58
|
On Friday, Mar 28, 2003, at 10:54 America/Vancouver, Greg Westin wrote: > If the digest option is used, it definitely needs to be an option... > keep > in mind that many people are still using basic authentication, for > whatever reason. I'm a bit confused on this point; I hope the proposed method wasn't to actually re-implement digest auth! ;-) As long as just the $REMOTE_USER environment variable is used, then both digest and basic should work fine (plus any other methods, like auth tokens, etc.). Am I somehow mistaken, or is "digest" just being misused? b. |
|
From: Greg W. <gr...@gr...> - 2003-03-28 18:55:02
|
If the digest option is used, it definitely needs to be an option... keep in mind that many people are still using basic authentication, for whatever reason. Greg --- http://www.gregwestin.com/ Contact info: http://www.gregwestin.com/contact.php On Thu, 27 Mar 2003, Chad wrote: > Well there shouldn't be any problem having both. In the config we would > then have two variables, one for the inclusion of an admin page, and > one for using digest authentication. This lets the end user decide how > secure they want their admin page to be. If digest is set to 'yes', the > need for username and pass goes away for futzing with files, though ftp > is still working behind the scene. Once you mock something up we can > look to see how well everything works. > > -C > > On Thursday, March 27, 2003, at 10:57 AM, Mike Traum wrote: > > > I was kind of thinking the way blaine is - using some sort of > > authentication besides ftp. If your going to offer ftp, you don't > > really need the admin interface. > > > > I'll look into adding digest as an option - sounds like a good idea to > > me. > > > > I'm a good part along - I should have something to show this weekend. > > > > mike > > > > > > > <image.tiff> > > > > Do you Yahoo!? > > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > |
|
From: Chad <ch...@ch...> - 2003-03-28 00:57:31
|
Well there shouldn't be any problem having both. In the config we would then have two variables, one for the inclusion of an admin page, and one for using digest authentication. This lets the end user decide how secure they want their admin page to be. If digest is set to 'yes', the need for username and pass goes away for futzing with files, though ftp is still working behind the scene. Once you mock something up we can look to see how well everything works. -C On Thursday, March 27, 2003, at 10:57 AM, Mike Traum wrote: > I was kind of thinking the way blaine is - using some sort of > authentication besides ftp. If your going to offer ftp, you don't > really need the admin interface. > > I'll look into adding digest as an option - sounds like a good idea to > me. > > I'm a good part along - I should have something to show this weekend. > > mike > > > <image.tiff> > > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: Mike T. <mt...@ya...> - 2003-03-27 18:58:45
|
I was kind of thinking the way blaine is - using some sort of authentication besides ftp. If your going to offer ftp, you don't really need the admin interface. I'll look into adding digest as an option - sounds like a good idea to me. I'm a good part along - I should have something to show this weekend. mike --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: Chad <ch...@ch...> - 2003-03-27 01:31:00
|
I would say most are not using webdav actually, and pretty much all can use ftp. -C On Wednesday, March 26, 2003, at 04:49 PM, blaine wrote: > On Wednesday, Mar 26, 2003, at 14:44 America/Vancouver, Mike Traum > wrote: > >> there will be only one user/password, which is configured in >> config.inc.php. afaik, this is a slight security problem, in that if >> something goes haywire with the server, it's possible that the text >> of config.inc.php could be obtained. That being said, it's the >> simpliest and I think sufficiently secure. >> >> Comments? > > I think an admin panel is a great idea; however, since most > phpicalendar installations will be using webdav, and therefore already > have some sort of Apache Basic (or digest) authentication enabled, it > would make more sense to use that (i.e., use the $REMOTE_USER > variable) --- perhaps a list of users who are allowed access to the > admin panel. > > Of course, there could always be an override password --- a username > isn't necessary. But in any case, it would be nice to be able to turn > this off, since it's always better to store passwords apart from the > web server's gaze than close to it ;-) > > b. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
6 messages has been excluded from this view by a project administrator.
