Serendipity Forums

Hi developpers! I'm working on an integration of s9y in a my customer's cms (c5) (hope you appreciate this^^ ) and run into severe problems with the cookies. I hope this is the appropriate forum for my questions.

I call s9y with cUrl from the same server, uncluding all cookies s9y sets (for the session). But s9y seems not to recognize the session: it sends me a new session cookie and doesn't find the captcha string in $_SESSION['spamblock']['captcha']. I have some questions about the beahviour of s9y. I would appreciate verye much if someone here had some answer, as I even have no idea where to search the problem:

If s9y is called the first time (new session...) it sets 2 session cookies, both with identical names. Why this? Do browsers really handle two cookies with identical names? I didn't find any information on this on the web. So if I send back both cookies with the next request, s9y gets me back 1 new session cookie. If I don't send them back, I get 2 new cookies (new session), if I send back only 1 of the two cookies (the second), s9y sets no new cookie (i.e. it recognizes the session, doesn't it?), but the captcha is not recognized the same! I don't understand, why. What's missing? Finally, if I send back only the first cookie, s9y tells me that no valid session hash was given.

Is there needed anything else beyond GET/POST-Parameters and cookies to manage the sessions?

Hope I could make clear what my problems are. Please ask me if not. Thanks for every hint!

Hi!

Recent version of s9y set their own session-ID, so maybe you are using a different session name for your php's/cms's session?

In the s9y development 1.6 version, we now do no longer issue a custom session name, if a session already exists; so you could use an auto-prepend script to initilaize your own session to make s9y use the same one.

Does that help you further?

Regards,
Garvin

Garvin - are you saying that 1.6 stopped using what was introduced in 1.5, which I think it the md5 value of the install path?

"...if a session already exists..."

kleinerChemiker wrote:"...if a session already exists..."

Just caught that distinction.

Hi Garvin,

thank you for your reply! I solved the problem in the meanwhile. It wasn't what you mentioned but your reply made me check again all http headers and find my fault: I didn't understand that the captcha string is set in the session when the captcha image is loaded and not with the page's get request! But I didn't wrap the image requests with my script, so the session-cookie wasn't sent!

Sorry for disturbing you and thanks for your help!