From: Blake C. <bl...@re...> - 2008-02-21 18:56:51
|
Wes, NICE!!! I'm trying to gain consensus for best practices. You've been quite helpful so keep being the 'annoying unsolicited adviser' even though I inquired initially. This was my dilemma, in short: User engineering has a calendar called managment. User management has a calendar called engineering (don't ask me how this would happen, users are supposed to do things like this). They both are allowed to post their calendars. Little do they know, they can't overwrite each others calendars cause they are locked to publish calendars as their user name. It allows me a greater piece of mind for the admin (me). Regardless, what projects are you devoting yourself too? Thanks, Blake Also, as far as being unsolicited... You were responding to my inquiry, so your simply Wesley Miaw wrote: > Hi Blake, > > Hm, that is a subtle difference. Is there not some combination of > username/everyone calendar list configuration that lets you let > everyone (authenticated or not) see all calendars, but also associates > a specific user with a specific calendar? I think if calendars aren't > in the blacklist, but are in the main list, there's no restriction > anyway? > > I've been pretty inactive in PHP iCalendar since I stopped using it so > much and have started working on different projects, which is why a > lot of my suggestions are in the form of questions. I'm just an > annoying unsolicited advisor now. > > Quoting Blake Cornell <bl...@re...>: > > >> Hey Wes, >> >> I believe your speaking of the apache_map config variable. That is >> likely the current way to do what I'm doing. It also allows multiple >> files per user. >> >> Currently, I'm allowing all calendars to be viewable by >> non-authenticated users. Only authenticated users can write to their >> user names calendar. Seems similar although subtly different. >> >> publish.php seems to be somewhat segmented to me, FYI. >> >> Thoughts? >> >> -Blake >> >> Wesley Miaw wrote: >> >>> Hi, >>> >>> I thought all the SF stuff automatically got moved over to SVN a while >>> back. Guess I didn't pay much attention. >>> >>> Blake, would it make some sense to try and build out a "default" >>> calendar file setting for users via the configuration file? I think it >>> might already be implicitly defined through the calendars you're >>> supposed to be able to see when you authenticate. Maybe the first >>> calendar indicated in the list. >>> >>> The only reason I'm thinking of it along these lines instead of >>> specifically to username is choosing the default calendar makes things >>> a little more flexible and is likely to apply to more deployments. >>> >>> I don't think publish.php is that integrated with the rest of the >>> authentication stuff, but I haven't looked at it myself as I never >>> used it. If it isn't integrated, perhaps it should be. And then some >>> things would be gained. >>> >>> I'm not entirely sure about the write permissions though.... >>> >>> Later, >>> Wes >>> >>> Quoting Jim Hu <ji...@ta...>: >>> >>> >>> >>>> Did someone just volunteer to migrate the cvs to svn? ;) >>>> >>>> Seriously, I would be in favor... but I haven't figured out how to use >>>> the sourceforge svn - I'm barely learning how to work with a local svn >>>> repository. >>>> >>>> JH >>>> >>>> On Feb 21, 2008, at 8:35 AM, Blake Cornell wrote: >>>> >>>> >>>> >>>>> Hey Wes, >>>>> >>>>> As far as committing it to the svn repo, the only feasible way to do >>>>> that would be via a new config var with an if switch at the proper >>>>> location. It wouldn't require much yet would offer the additional >>>>> option. I would describe it in a PRD as `Adhere Calendar Name to User >>>>> Name`. In the least, I figure I offer up my experience. >>>>> >>>>> Is there another way to allow multiple users authenticated write to user >>>>> specific files within the same directory? I know there is the sub >>>>> directory way thats described in the wiki. >>>>> >>>>> Do you think this added logic can perform more to current specifications >>>>> rather then simply hacking the publish code? >>>>> >>>>> Thanks, >>>>> >>>>> Blake >>>>> >>>>> >>>>> Wesley Miaw wrote: >>>>> >>>>> >>>>>> Hi Blake, >>>>>> >>>>>> That change seems to make it do something completely different than >>>>>> before.... But if that is what works for you I don't see any problem. >>>>>> It doesn't seem like something that should get merged into the >>>>>> repository though. >>>>>> >>>>>> Regards, >>>>>> Wes >>>>>> >>>>>> Quoting Blake Cornell <bl...@re...>: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I've had issues assigning apache basic auth to allow particular >>>>>>> users to >>>>>>> load particular calendars. The filename didn't transport properly and >>>>>>> thus creating a '.ics' file instead of ex. 'engineering.ics' or >>>>>>> 'management.ics'. >>>>>>> >>>>>>> I've added the following function to publish.php. >>>>>>> >>>>>>> >>>>>>> function retUser() { >>>>>>> if( $_SERVER['PHP_AUTH_USER'] ) >>>>>>> return $_SERVER['PHP_AUTH_USER']; >>>>>>> else >>>>>>> return $_SERVER['REMOTE_USER']; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> and I've modified the follow line of code >>>>>>> >>>>>>> if($dataout = >>>>>>> fopen($calendar_path.$calendar_name.'.ics','w+')){ >>>>>>> >>>>>>> to.. >>>>>>> >>>>>>> if($dataout = >>>>>>> fopen($calendar_path.retUser().'.ics','w+')){ >>>>>>> >>>>>>> >>>>>>> Now its working great. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Blake >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> This SF.net email is sponsored by: Microsoft >>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>>> _______________________________________________ >>>>>>> Phpicalendar-devel mailing list >>>>>>> Php...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by: Microsoft >>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>> _______________________________________________ >>>>> Phpicalendar-devel mailing list >>>>> Php...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >>>>> >>>>> >>>> ===================================== >>>> Jim Hu >>>> Associate Professor >>>> Dept. of Biochemistry and Biophysics >>>> 2128 TAMU >>>> Texas A&M Univ. >>>> College Station, TX 77843-2128 >>>> 979-862-4054 >>>> >>>> >>> >>> >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> >> > > > > |