Remove $_SESSION dependency

[GoogleCodeExporter]

It would be nice to not be reliant on $_SESSION. The "store" stuff could be 
used for it instead.

Original issue reported on code.google.com by masterch...@googlemail.com on 12 Nov 2009 at 6:28

[GoogleCodeExporter]

Agreed.

Original comment by brunobg%...@gtempaccount.com on 12 Jan 2010 at 6:54

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Is there any anticipated timeline to this dependency being removed?

Original comment by philfreo on 5 Apr 2010 at 5:22

[GoogleCodeExporter]

Hi, not yet. Why is using _SESSION a problem for you?

Original comment by brunobg%...@gtempaccount.com on 7 Apr 2010 at 7:50

[GoogleCodeExporter]

_SESSION is difficult to get working when you have a large site scaling across 
multiple servers.  Does it really 
need to use sessions?  Can it use the app's own user ID (rather than a session 
cookie) and store the data in the 
database?  It'd be good if there was separate instance of something like Store, 
where you could choose between 
$_SESSION, using Memcached, the database, etc.

Original comment by philfreo on 7 Apr 2010 at 7:57

[GoogleCodeExporter]

I see, but doesn't session_set_save_handler() already provides what you are 
looking for? 

I'm afraid that people will need lots of different store options and each will 
need
to be highly customizable to work efficiently with the rest of existing code.

Original comment by brunobg%...@gtempaccount.com on 8 Apr 2010 at 1:03

[GoogleCodeExporter]

I think session_set_save_handler() is the wrong way to go here.  It seems like 
this framework shouldn't be dependent upon 
$_SESSION, but rather use a generic interface.  The point is that you don't 
have to write each person's different needed store 
option/implementation, but rather that the framework provides an extendable 
class or interface that can be used as a base.

For example, none of the framework's provided Store implementations worked for 
exactly what I needed, but because it was set 
up nicely I could create a class that extended the OAuthStoreSQL class -- 
without modifying any of the framework's classes -- 
to fit my implementation.  It'd be much better if $_SESSION was similarly 
abstracted, and just provided a simple implementation 
that used $_SESSION that would work for the majority of simple cases but not 
make the entire framework dependent upon it.

What, exactly, is $_SESSION being used for now?  Can it use the app's own user 
ID (rather than a session cookie) instead?

Original comment by philfreo on 9 Apr 2010 at 6:59

[GoogleCodeExporter]

Ok, I see.

$_SESSION is being used by the authorization verification code. I've carefully
analyzed the code, however, and there seems to be no need for using _SESSION or 
any
similar persistent storage. Since it's Friday evening :) I'll check with the 
original
writers to see if I'm missing something (perhaps there is a case where it makes 
sense). 

If necessary, I'll write the new storage classes. 

BTW, if your code changes could be useful to other people, send me a patch and 
I'll
include them on the next release.

Original comment by brunobg%...@gtempaccount.com on 9 Apr 2010 at 11:43

[GoogleCodeExporter]

Great! Looking forward to seeing what happens with it.

I'll definitely be sure to submit any code that I think could be of use to 
others.

Thanks!

Original comment by philfreo on 12 Apr 2010 at 5:03

[GoogleCodeExporter]

Revision 106 has the new code with the _SESSION dependency removed. It uses a 
system
analogous to the store, and I implemented only the _SESSION class. 

To those watching this issue, if you create another session class, please send 
the
code and I'll add to the SVN and next releases. If you need to make changes to
OAuthSession talk to me.

I tested the code and it's working. Since it's a pretty straightforward change, 
I'll
consider this fixed and wait for the tons of session classes you will send me ;)

Original comment by brunobg%...@gtempaccount.com on 16 Apr 2010 at 6:35

• Changed state: Fixed

[GoogleCodeExporter]

Overall the changes look good to me!.  (Still haven't finished fully testing 
though)

Looks like OAuthSessionSESSION.php declares it as an abstract class but it 
shouldn't.
OAuthSession.php - line 44 - default $store parameter value should be 'SESSION' 
rather than 'Session' if the file 
name is going to remain all uppercase.

Original comment by philfreo on 20 Apr 2010 at 5:49

[GoogleCodeExporter]

Also, the OAuthSessionSESSION doesn't extend OAuthSessionAbstract like it 
should.
(these comments are as of r108)

Original comment by philfreo on 20 Apr 2010 at 5:51

[GoogleCodeExporter]

Fixed.

Original comment by brunobg%...@gtempaccount.com on 20 Apr 2010 at 2:18

• Changed state: Started

[GoogleCodeExporter]

I just remade all my tests and caught another bug. The session code validated 
now
(r114). 

Original comment by brunobg%...@gtempaccount.com on 20 Apr 2010 at 3:24

[GoogleCodeExporter]

Since I've tested this and I'm already running on an internal server with 
success, if
nobody has anything else to add in the next few days I'll consider this one 
closed.
Thank you all for the feedback.

Original comment by brunobg%...@gtempaccount.com on 28 Apr 2010 at 5:48

[GoogleCodeExporter]

Trying to test the latest version and am not sure the best place to report this.
When trying to run mysql.sql... I get the error below.
Please make sure that both the comments at the top "ALTER TABLE" are up to 
date, as well as the actual file for 
fresh installations.

---
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that 
corresponds to your MySQL 
server version for the right syntax to use near '(128) not null,
ost_token_ttl           datetime not null default '9999-12-31',
' at line 9

Original comment by philfreo on 1 May 2010 at 7:59

[GoogleCodeExporter]

@philfreo: the file had some tabs, which were being rejected by mysql. The file 
is up
to date and I removed the tabs. Fixed on r121. Thanks for the report.

Original comment by brunobg%...@gtempaccount.com on 3 May 2010 at 7:37

[GoogleCodeExporter]

Closing this. 

Original comment by brunobg%...@gtempaccount.com on 6 May 2010 at 3:00

• Changed state: Fixed