next »

[TDPSS]

I captured the the Navigator Bar for each step in #1 login as Admin, #2 selecting Admin button, #3 selecting an option.
It appears the third URL is getting changed. Interesting enough, those numbers are also part of the Full Direct path
in BASE_DIR. i.e. $BASE_DIR = "/data/13/1/89/138/1252627/user/1336072/htdocs/calendarscript/";

Also, FYI
The config URL's are:
---------------------------------------------------------------------
calendar_url=http://www.PowellButteCommunityCenter.com/cgi-bin/calendar.pl
calendar_admin_url=http://www.PowellButteCommunityCenter.com/cgi-bin/calendar_admin.pl

Navagator Bar Capture:
------------------------------------------------------------- http://www.powellbuttecommunitycenter.com/cgi-bin/calendar.pl      <Admin Login>  Calendar with AdminLogon display http://www.powellbuttecommunitycenter.com/cgi-bin/calendar_admin.pl?calendar=default      <selecting Admin button>    Main Menu displays http://www.powellbuttecommunitycenter.com/~1252627.1336072//cgi-bin/calendar_admin.pl?template=calendar_settings.html   <selecting option on Main Menu>
-------------------------------------------------------------

Anymore ideas on what's happening ?
-Dennis

------------------

[TDPSS]

***I myself however, usually just extract the files locally (either .zip or .tar.gz) and then FTP those files in ascii mode to the server, preserving their directory structure. Once there i chmod the three .pl files if necessary (it often isn't).***

When I started this project, I thought it would be much less complicated to fully develop and test first on a local HOST system. I felt a crawl, walk, run approach was best, as I'd consider myself near Neanderthal level when it comes to Perl & CGI. Also, I didn't know from the get-go that 99% of the changes would only be to default.html, plus the BASE_DIR *.pl changes, and URL config.txt, etc.

Even so, with all the FTP xfr issues, I'm not sure I'd upload first and then transfer beta files during the development phase. I was far more productive on a stand alone machine. I think the key issue is how to make CalendarScript less prone to these installation issues. I for one can think of many suggestions, but my focus now is trying to get this Project on-line ASAP.  

Thanks for your inputs.
-Dennis

------------------

[DanO]

** It appears the third URL is getting changed. Interesting enough, those numbers are also part of the [absolute] path **

They are not "changed", they are being generated incorrectly. The script makes them 'on the fly' when it is run.

Your server may not be reporting the $ENV{'SCRIPT_NAME'} and/or $ENV{'REQUEST_URI'} environment variables properly. Check the previous forum message, "calendar_admin.pl error" to see if its suggestion works for you.

** I think the key issue is how to make CalendarScript less prone to these installation issues. **

Yes, like maybe design it to only run on one particular computer software. Unfortunately, the Internet is full of hosts running different hardware, operating systems and server software versions, each can be set up totally differently from any other at the whim of the administrator. It is impossible to predict all the possible problems that could crop up when you write a script to transverse a wide range of environments. That is what the individual host's support is for.

JMO

Dan O.

------------------

[TDPSS]

One "temporary" solution, since CalenderScript functions for non-Admin users doing plain ADD,EDITS & DELETES work, is I could do Admin stuff, back on my development Local Host and transfer the appropriate files up, other than the Event Datbase itself.
Normally, once the CalendarScript has been stylized and stable  further changes should be minimal. Also, the group of login Users is limited to only four event managers with very limited permissions. I think this mode would surfice for now. Assuming I get my understanding of what files could be transfered, under control.

I assume I could get away with this scheme if I left ./calendar/default data on the DomainServer untouched.
What do to think?  Also, should I elevate this to DomainHost support?
-Dennis

------------------

[DanO]

The .../calendarscript/calendar/default should contain all the event data, yes.

** should I elevate this to DomainHost support? **

They will not usually help getting a 3rd party program they did not supply running... besides for possibly problems which might be caused by their server configuration. You could try asking if you wanted though.

Dan O.

------------------

[TDPSS]

**They are not "changed", they are being generated incorrectly. The script makes them 'on the fly' when it is run.**

I thought this statement from above indicated the "they" was the DomainHost guys. If it's true it's incorrect on their part then I have a leg to stand on. Again, my knowledge of what calendar_admin.pl is trying to do under the hood is very very limited, so it would be helpful to know more if I'm to converse with the support staff at my Domain Site.

For me it's a simple question of - Is there an alternate way for calendar_admin to achieve whatever on this issue, or get the Host people to fix whatever they're doing incorrectly?  

I'm still confuse about whether the issue was caused by moving calendarscript to htdocs, or the underlining issue was always there regardless. Since, moving calendarscript on my local host system works, I suspect the latter.

In addition, if it's truly a design/implementation issue - it would be very helpful to know whether you guys are seriously looking at this and I should be more patience.

If you need more info about what's really happening to/in calendar_admin in the environment of my Domain-Host, then maybe you could supply a little test.pl for me to run. I'd be more than glad to continue helping in whatever limited knowledge I have.

By the way, since this Topic no longer deals with $BASE_DIR issue but Calendar Admin script failure in an adverse environment, should I begin a new Topic?

Also, as a side bar - the whole purpose of the website I'm developing is centered around this application. It's a community center event scheduler and any consideration to dump this and start over is a huge impact.

-Dennis

------------------

[DanO]

 

quote:**They are not "changed", they are being generated incorrectly. The script makes them 'on the fly' when it is run.**

I thought this statement from above indicated the "they" was the DomainHost guys.

"They" refer to the links. Those links are created on the fly by the program as it is run, from the information available in the system variables (namely the $ENV{'SCRIPT_NAME'} and/or $ENV{'REQUEST_URI'} environment variables).

** I'm still confuse about whether the issue was caused by moving calendarscript to htdocs **

I do not think moving the files is the problem with the links being generated incorrectly in the drop down menu selector. It has to be the server information available to the script in the system environment variables being used.

** it would be very helpful to know whether you guys are seriously looking at this and I should be more patience. **

*I* an only a volunteer here, *I* am not looking into anything. Matt (the script's author) AFAIK isn't planning any changes to the script in the near future.

** If you need more info about what's really happening to/in calendar_admin in the environment of my Domain-Host, then maybe you could supply a little test.pl for me to run. I'd be more than glad to continue helping in whatever limited knowledge I have. **

Thanks but if you want my personal assistance, I charge for that. As I stated, I an only a volunteer here.

** should I begin a new Topic? **

IMO it would be best to keep all information that was been discussed thus far together so starting a new thread now would quite possibly confuse things.

JMO

Dan O.

------------------

[This message has been edited by DanO (edited May 12, 2007).]

[TDPSS]

To those who are volunteers - many many thanks for your efforts. I in no way want to make your efforts appear un-appreciated. My assumption that there was some form of Vendor support is based on the Initial statement in the Support page.

** Get peer-to-peer support from other users, as well as "receive official answers" from the CalendarScript.com **

If the official line from CalendarScript is it's up to you users to figure it out, then I should have waited on purchasing the license from the get-go and spent a lot more time evaluating. My fault was totally under-estimating the complexity with installing on a remote Domain Site. Anyway, enough of the rant, I still want to solve this issue as I beleive fundamentally the product is a good one from a Users view.
I only hope Kruse buys you guys pizza once in awhile.

The latest update is as follows:
#LOCAL SYSTEM:
I have duplicated <calendarscript>'s, one in htdocs the other in cgi-bin. By merely change BASE_DIR back and forth I can easily switch between both setups. The cgi-bin setup version <as to be expected> works fine calendar_admin.  The htdocs version works OK only if the calendar_admin.pl "Template::CGI_URL" is left as original code. Swapping these <as indicated above> causes simular non-functionality that I see on Domain Host. The "Calendar Administration : Main Menu" comes up, but is non-functional.

#DOMAIN_HOST:
The only setup allowed <by their rules> is calendarscript directory operating under htdocs. With the "Template::CGI_URL" left as original, the page CRASHES. With the swap <as indicated above>, the "Calendar Administration : Main Menu" comes up, but is non-functional.

I have already reported the URL mangling to NetworkSolutions and they are looking at it. But this was on the swapped "Template::CGI_URL" version running on their site. Though I most likely won't hear anything for a few days, I wonder if I should return that parameter back to it's original, since the swap is bogus on both Local and Domain systems.

I hope this all sheds further light on the matter.

-Dennis

PS/ For you volunteers, I'll surpress the Rant!

------------------

[DanO]

** The cgi-bin setup version works fine calendar_admin.  **

Than use it.

JMO

Dan O.

------------------

[TDPSS]

Are we going in circles here. The reason for having to put the calendarscript in the htdocs area is because of Domain Host rules that do not allow HTML's in cgi-bin. The reason for posting various test cases on both my LOCAL system vs the DOMAIN HOST was to provide some insite that may trigger some helpful response. Base on the quality of the above response, I sense no interest and I might as well quit posting.

------------------

[DanO]

** Domain Host rules that do not allow HTML's in cgi-bin. **

Is it an arbitrary "rule" or were they just stating/warning that such files would not be viewable there??

My guess is the latter... which is actually good because such a case will protect those (and likely any other files, besides the actual script files) from prying eyes.

JMO

Dan O.

------------------

[TDPSS]

Have the security issues with CalendarScript posted on the Web been dealt with?

See these sites:
--------------------------------------------------- http://www.securityspace.com/smysecure/catid.html?id=10506
http://neworder.box.sk/news/1351
http://www.securityfocus.com/bid/1215/exploit

-Dennis

------------------

[DanO]

Now that could have been posted in a separate message as it has nothing to do with anything that has been yet posted in this message.

I'm afraid 2 of the links you supplied do not give details of the product version they are referring to. One is about 01/12/2001, version 1.3 (First Released Version). What version have you got installed??

For changes that have been made to CalendarScript since version 3.0 was released 11/18/01, see the CalendarScript History file

Dan O.

------------------

[TDPSS]

Security may be a backdoor issue on Template::CGI. All I know is my Domain site has issues with *_admin.pl and it's environmental variables, which they claim vulerabilities.

I'm still trying to sort through what restrictions "they" are imposing on perl scripts and the cgi-bin environment. I did a google search on security issues and those links above were in the list. I am developing on version 3.21, so any question about security issues should be limited to that version. If the above links have NO bearing on version 3.21, then please delete the above POST. I certainly don't what other user chasing a red herring.  

-Dennis

------------------

[DanO]

Matt (CalendarScript's author) addressed security concerns in CS version 3.21 in the forum message, "Calendarscript can be hacked by outsiders?". Look for the posts by "Scott".

Dan O.

------------------