GrinnellPlans update

5 views
Skip to first unread message

Athanasakis, Theocharis Ian

unread,
Sep 27, 2008, 9:45:05 PM9/27/08
to Erin O'Neil, Jonathan Wellons, Grinnell Plans, Greg Fuller, grinnellplan...@groups.google.com
Greetings,

I just wanted to let you know that I have moved all the active
GrinnellPlans code to http://code.google.com/p/grinnellplans/ . Soon
we will have all the old bugs as well. The Google Code SVN repository
includes Ian Young's efforts to make Plans XHTML compatible.

Another big change that is live as of today on the server (and is of
course in the SVN):

** _SESSION ** changed! Instead of saving the session information on a
file on the server (the default PHP behavior) we now store them in the
cookie, encrypted (to ensure no one tampers with it). This means,
faster (less disk IO involved) and also, we can, ideally, swap web
servers without any user-noticeable disruption since all their session
metadata is stored in the cookie.

To use sessions one _must_ include cookie_session.php . I will be very
careful with what is included in the SVN—no passwords, no SQL dumps,
no weird random stuff.

Also, people who have access to the production server: changes made
directly in the server code (except Configuration.php) WILL be lost.

Ian.

mab...@gmail.com

unread,
Sep 29, 2008, 12:29:13 PM9/29/08
to GrinnellPlans Development
For anyone looking to maintain a local dev environment, I've found a
few things so far. First up is that the Doctrine libraries used for
ORM now require PHP to have the MySQL PDO adaptor installed. If you
try to log in and get errors from require_once about Doctrine/Adaptor/
Mysql.php not being found then you will need to enable it for your PHP
installation. Depending on how you're running things it could be as
simple as uncommenting a line in your php.ini file or you may need to
compile it from source. I'm using OS X 10.5 and found this helpful:

http://gidden.net/tom/2008/06/30/mysql-and-pdo-on-os-x-leopard-intel/

But I skipped recompiling MySQL since I didn't care about perl and
instead opted to change tha -arch flags in his php module configure
statement to make it 64 bit.

The mcrypt library is required too, which is a PHP module and may need
to be installed or enabled for your system.

There is at least one change to the schema, but the new schema is
included in documents/db-schema .

There is an IP geographic lookup function now, which requires a pear
library (I think) Net_GeoIP to be installed.

Anyone found anything else? Is the local plans setup page on the wiki
still active or is documentation moving to google groups along with
the source code?

--James Michael-Hill [michaelh]

On Sep 27, 9:45 pm, "Athanasakis, Theocharis Ian"
<athan...@grinnell.edu> wrote:
> Greetings,
>
> I just wanted to let you know that I have moved all the active
> GrinnellPlans code tohttp://code.google.com/p/grinnellplans/. Soon

Ian Young

unread,
Sep 29, 2008, 12:34:15 PM9/29/08
to grinnellplan...@googlegroups.com
As of last night, the wiki pages have been moved to the Google Code
project page. The page you're probably wanting is at
<http://code.google.com/p/grinnellplans/wiki/DeployGrinnellPlans>.

Ian

Greg Fuller

unread,
Sep 30, 2008, 11:14:10 PM9/30/08
to grinnellplan...@googlegroups.com
It would appear that someone has figured out how to decrypt/encrypt their user stuff in their cookie.  I haven't looked into it that closely, but someone is submitting to notes as userid 0.  The cookie change is the only one I can think of that would make this possible that's different as of today.

Avram Lyon

unread,
Sep 30, 2008, 11:49:11 PM9/30/08
to grinnellplan...@googlegroups.com
Unless I'm missing something, the cookie setting code (in
SessionBroker.php, right?) does nothing to prevent me from forging
cookies. I just have to encrypt them correctly...

In general, I don't see the logic in moving the session data to the
user-agent; we only _need to_ maintain user id in the cookie, so we're
not talking about a lot to pull from the database. Why can't we go
back to cookies holding session identifiers, and the real data living
on the server? I don't see that increasing server disk I/O or even
improving the user experience.

Avram

Greg Fuller

unread,
Sep 30, 2008, 11:51:09 PM9/30/08
to grinnellplan...@googlegroups.com
If you look at the most recent notes thread, you'll see that /geo/ is somehow changing the cookie to make people not-really logged in.
Reply all
Reply to author
Forward
0 new messages