Forum .LRN Q&A: Problem with safari navegator, (I have a problem with Mac and Safary.)

I have a problem with Mac and Safary.

Im using .LRN in a mac and with the Safary explorer, when i try to validate in .LRN it goes another time to the register page as nothing had happened.

When i try it with firefox or IE explorer for mac i find no problems.

Can some1 give me a clue?

Thanks.

Hi Sergio,

It sounds like a cookie problem. Is your installation using standard cookies of openacs/dotlrn? Also, check if Safari is accepting cookies.

Hello Emmanuel!

Yes, we are using standard cookies.
In fact, this worked in our old platform.

I have investigated a little the problem and seems as if the
cookies of session will not behave in this navigator
in the same way. Konqueror, from KDE, have the same problem.

Any pointer to cheer the day to MAC users 😊 ?

Regards,
Agustin

Hi Sergio,

I'm posting this message using Safari 2.0, have never had a problem with it nor with the previous version.

The only advice I could give, as Emmanuelle said, is to check if your browser is accepting cookies.

Regards,

Derick

Hi Agustin:

I've tested with oacs-5-2 and safari and results are:

non-persistent login: can't login
persistent login: can login but can't logout

The language of the machine where my server is, is french; I guess yours is spanish. The content of the set-cookie header is:

ad_user_login=494%.....; Path=/; Expires=Mon, 01-Jan-2035 01:00:00 GMT
ad_session_id=130.....; Path=/; Max-Age=1200; Expires=dim, 16-oct-2005 11:33:14 GMT

The difference is in the expires date format, for ad_session_id is in french. I hardcoded the expires date in ad_set_cookie using english ("Expires=Sun, 16-Oct-2005 ..." instead of "dim, 16-oct-2005") and I could login/logout normally.

The expire date is obtained with ns_time, so we have to reformat this date.

To complete my last post: the date obtained with ns_time is formatted using util::cookietime that use ns_httptime; ns_httptime will format the date according to the locale of the system where aolserver is running.

On the other hand, I've tested again on safari (version 2.0.1, Tiger) but this time with our oacs-5-1 based installation and there is the same problem. I'm not sure that this problem exists with previous versions of Safari, that's maybe why you didn't notice it before.