73 replies to this topic

[espersen]

atm not easy to overlook what fixes is out

It would be nice if
a. the are included in the available download-package or
b. the fix'es are gathered in one spot - fx using the ShowFiles-snippet - easy and ready for download.

[Jelmer]

The fixes are all gathered in one forum thread, which is http://www.etomite.com/index.php?sh...t=0&#entry32463 in the Announcements section. Looks ok to me.

It would be very unwise to include all fixes in the download immediately because we would have dozens of different releases.

[Dean]

Not only that, but it took us bloody ages how to figure out how to get the downloads up there to start with

[shanester]

I installed the authenticate visitor snippet. The form appears properly and so forth, but it fails to generate a proper redirect url when I have FURLS enabled. If I don't have FURLS enabled and I pass the ID, it works fine. I have all the fixes Jelmer linked to above installed. I have tried FURLS both with and without friendly aliases, but it fails no matter whether I call the snippet with the ID or the alias (haven't tried the url call).

If I call with id=2 with FURLS enabled, the url that's generated for redirect is:

"http://www.longtins.com/cm_test/2.html"

which fails, of course. If I instead pass alias=repository, I get:

"http://www.longtins.com/cm_test/repository.html"; or
"http://www.longtins.com/cm_test/.html"

depending on whether FALIASES are enabled, both of which also fail (though I think the "repository.html" one should work since FURLS are enabled??). I suppose it's not crucial that I use FURLS, but I'd like to. I'm on Prelude Final. Suggestions?

[mikef]

shanester, on Jun 3 2006, 08:59 AM, said:

Suggestions?

Read the documentation on setting up Friendly URLs, and, if necessary, the long thread on setting up FURLs. .../2.html and .../repository.html are both potentially valid if FURLs are set up properly.

edit:
... and make sure the page you are trying to redirect to is published! repository seems an odd choice ...

Edited by mikef, 03 June 2006 - 08:15 AM.

[Jelmer]

Please discuss the FURLs problems in that appropriate thread. If they are properly working but not in this snippet, this is the place

[shanester]

Pardon my ignorance and newbieness. I thought I had everything enabled properly, but forgot to rename the ht.access files. The snippet now appears to be generating the proper urls, but functional FURL problems remain, which I will take to the appropriarte section.

[Ralph]

shanester, on Jun 3 2006, 10:01 AM, said:

Pardon my ignorance and newbieness. I thought I had everything enabled properly, but forgot to rename the ht.access files. The snippet now appears to be generating the proper urls, but functional FURL problems remain, which I will take to the appropriarte section.

That'll do it... Glad you got things sorted... :betterwink: Welcome to Etomite...

[mikef]

Authenticate_visitor is not working correctly with this Windws server based configuration phpinfo.

If I log in with the correct id and password, it just redisplays the login form; it doesn't display 'logout' instead, so $_SESSION['validated'] must be false, looking at the code. The EtoGal page I'm using it for also fails to detect that anyone is logged in; it uses the code

$userdetails=$etomite->userLoggedIn();
  if($userdetails['id']) { 
...

to detect if anyone is logged in.


If I attempt to login using an incorrect password, an error message is printed saying that the password is invalid, so its not that I've got the password wrong!

Edited by mikef, 18 June 2006 - 03:40 PM.

[Ralph]

mikef, on Jun 18 2006, 11:40 AM, said:

Authenticate_visitor is not working correctly with this Windws server based configuration phpinfo.

If I log in with the correct id and password, it just redisplays the login form; it doesn't display 'logout' instead, so $_SESSION['validated'] must be false, looking at the code. The EtoGal page I'm using it for also fails to detect that anyone is logged in; it uses the code

$userdetails=$etomite->userLoggedIn();
  if($userdetails['id']) { 
...

to detect if anyone is logged in.
If I attempt to login using an incorrect password, an error message is printed saying that the password is invalid, so its not that I've got the password wrong!

Can you post the snippet call code that you are using... I'm wondering if the install you are using isn't maybe more sensitive to the variable types being passed in the snippet call... I am referring to how something like use_logout=1 might be interpreted as "1" rather than true... I have seen this described problem before but not sure whether it may be an issue in your circumstance...

[mikef]

Ralph (rad14701), on Jun 18 2006, 05:28 PM, said:

Can you post the snippet call code that you are using... I'm wondering if the install you are using isn't maybe more sensitive to the variable types being passed in the snippet call... I am referring to how something like use_logout=1 might be interpreted as "1" rather than true... I have seen this described problem before but not sure whether it may be an issue in your circumstance...

[[authenticate_visitor]]

ie, defaults used. all pages are uncached.

[Ralph]

mikef, on Jun 18 2006, 12:37 PM, said:

[[authenticate_visitor]]

ie, defaults used. all pages are uncached.

Have you tried [!authenticate_visitor!]...???

[mikef]

Ralph (rad14701), on Jun 18 2006, 07:58 PM, said:

Have you tried [!authenticate_visitor!]...???

No ... it shouldn't be necessary when the page isn't cached, and I know the snippet is being executed anyway (as I said before, it gives an error if I give the wrong password). The fact that the screen isn't updated correctly is merely confirmation that there's something wrong with the authentication, as EtoGal (on another page) also fails to detect that the user is logged in. (If I provide the page id, authenticate_visitor does cause it to go to the new page.) The problem may not be in authenticate_visitor itself, of course, it could be in the routines in index.php which probably haven't been that well tested for a Windows server environment. (As noted elsewhere, I've already had to patch an error in index.php and config.inc.php to get the right URL generated.)

[Ralph]

Are you using all of the currently patched files, by chance...???

[mikef]

Ralph (rad14701), on Jun 18 2006, 08:44 PM, said:

Are you using all of the currently patched files, by chance...???

Unlikely.

I have what I believe is the current latest index.php, and it has the error in the code for generating the protocol. I don't recall there being any advice that any of the patches needed to be applied before installation, so none would have corrected the error in config.inc.php.

I'm not a believer in replacing code with patched versions that solve unknown problems in the hope that they won't break anything else and might just happen to address this problem. patches generally get tested for the problems they aim to solve, rather than full regression testing.

I have no idea what the current set of patched files are, because they aren't gathered together in a coherent fashion, with what they fix.

I'll look at the code in the relevant routines later, and see if I can find anything, but the will probably not be before tomorrow evening.

Edited by mikef, 18 June 2006 - 08:14 PM.

[Ralph]

mikef, on Jun 18 2006, 03:55 PM, said:

Unlikely.

I have what I believe is the current latest index.php, and it has the error in the code for generating the protocol. I don't recall there being any advice that any of the patches needed to be applied before installation, so none would have corrected the error in config.inc.php.

I'm not a believer in replacing code with patched versions that solve unknown problems in the hope that they won't break anything else and might just happen to address this problem. patches generally get tested for the problems they aim to solve, rather than full regression testing.

I have no idea what the current set of patched files are, because they aren't gathered together in a coherent fashion, with what they fix.

I'll look at the code in the relevant routines later, and see if I can find anything, but the will probably not be before tomorrow evening.

Just use the patched files... They solve problems... Period... If I wasn't entirely confident that the files are better than the files they replace they never would have been posted for use... Changelog or no changelog, the newest files are the ones to use if you are having any problems...

[mikef]

Ralph (rad14701), on Jun 18 2006, 09:45 PM, said:

Just use the patched files... They solve problems... Period... If I wasn't entirely confident that the files are better than the files they replace they never would have been posted for use... Changelog or no changelog, the newest files are the ones to use if you are having any problems...

OK, I've used them. Corrected the protocol bug in index.php again. no change.

calling authenticate_visitor with no params, either using [[ or [!

with the correct password, the necessary session variables aren't set when the page is refreshed, the full set being:

<!-- session :_logging_first_hit:1: -->
<!-- session :visitorLogged:1: -->
<!-- session :userAgentLogged:1: -->
<!-- session :operatingSystemLogged:1: -->
<!-- session :hostNameLogged:1: -->

with an incorrect password, I get an error message
with the correct password, and an id set for the target page, it goes to the target page; the required session variables are still missing.

[Ralph]

mikef, I wasn't able to get to the phpinfo via the link... This one's got me intrigued...

[mikef]

Ralph (rad14701), on Jun 19 2006, 03:01 AM, said:

mikef, I wasn't able to get to the phpinfo via the link... This one's got me intrigued...

Works for me ... http://test.artgocollective.co.uk/phpinfo.php ... maybe the server or something was offline? The site is on http://test.artgocollective.co.uk/example/

[jkn]

Hi,

Can anyone help me with sessions and authenticate_visitor?
I have this snippet and user can successfuly login (for gallery managment), but I want to give him oportunity to log into Etomite manager with current session. Simple redirection through link <a href="manager/index.php"> cause starting of new session and user have to log-in again.
I'm not a professional webmaster, please, forgive me if the question is simple

regards,
Jakub