Search options (Page 2 of 8)

So IOW, ...

So then I can get away with
pun_setcookie(, , $expire);

Or Must I do:
pun_setcookie($cookie['user_id'], $cookie['password_hash'], $expire);

Nope, I think that's not correct.
In fact, it appears that, in the functions.php file (which definitely gets called for a cookie check via common.php anytime we do things)
...the cookie gets updated (pun_setcookie) only if authentication fails.  So either the 'so-called'  timer runs out, or the user set save_pass so the timer does not matter

So in fact, it appears there is no code written there that checks the updated $expire time(r), and then updates the cookie with the new $expire value!

So if I didn't overlook somethng or misunderstnad the check_cookie functionality, then it would seem I need to write a little bit of code that will do just that.

Your input on this is most welcome.

(Oh and @Divnain, yeah, I already took care of all that, thanks.)

All righty then... I'm in the saddle now - thank you so much, Smartys!

Okay.  Well, I located those files and, along with the changes mentioned above [post#5 regarding editing in functions.php file], I changed each occurance of "time() + xxxxxxx"  in the other files (where it related to cookie stuff) to "time() + 1" ,
...but the user still stays logged in after a lengthy idle time :^(

Just to mention, for testing I use a separate browser that is storing its own cookies, and  I log the user instance out, and then log it back in.  I can see the "end of session" cookies being set each time I log the user instance in.

`8^|

Hi Smartys.  Thanks. 

I am still observing results different than expected. Please allow me to explain and try to obtain better clarity as to how this should work..

First, to be clear, I reset everything back to how it was originally (i.e., stock, or when downloaded).

Now let me see if I understand this proper...
If, right near the beginning of functions.php file where "cookie stuff" is setup...
$now = time()  (no changes made)
and then $expire is changed to something like  "= $now + #;" ...where # is some number representing seconds,
..then what should happen is the session cookie should expire after the # of seconds set, and also if/when the browser is closed...
Is this correct?

If so, some questions remain...
1) I do observe the session requiring login after closing and then reopening the browser, so no question there (except I do not know why it was not doing this before [smegma?].
2) I do not observe the session timing out (resetting and requiring a login) after  "#" of seconds of user inactivity.  Why is this?  Can I change it?
3) I do not observe the session resetting if I close a browser tab?  Can I enforce that?
4) How is any of this possibly related to "Save Username and Password between visits" setting in user's profile:privacy, and how would I over-ride that?

Cheers (and thanks for your, as always, indefatigable support ;^),
TwoHawks

No I did not do that.  I immediately checked the tables after recreating that group and the difference I mention was immediately apparent.  Willow (only other admin) could not have interfered either because at the time she was not at a computer.

I think the only thing left to do is... I have to do my homework, as mentioned above, and then very carefully record what takes place.

I hope to take time out over the weekend periodically.  I will wait until I assemble substantive and uniform information, and in the form of a demonstrable excersize for exposing an issue, if there is one that is not "user-error" related  ;^)

Thanks again, Smartys... I am very grateful for your assistance today.
Be well,
Two Hawlks

Question, If I turned off read and post permissions for Validating (after recreating) then why would we have to go in and turn off the Post checkmark that appeared afterward in several forums?  Should it not become disabled when I turned those attributes off?

Hmmm... but we used to give Guests read permissions, but right now if you turn that on you will observe they see Forums Christina, Two Hawks, and a small group, in the list (when not logged in, right)... and you cannot turn that off... but we always were able to before.

I clicked on your email link and sent you something.  Did you get it?  Is this something you wish to do and have time for?

Nope, admin_groups.ph only has the view_users edit in it, applied two days after I deployed PunBB1.2.12 back in Sept last year. 

So I really do not htink its anything to do with changes to these files at all.

Thanks for looking at this, Smartys.

Hmmm...  Well I wonder why when I 'rebuilt' (so-to-speak) the Validating Group that the new Validating Group then was included with the rest of the forum_id associations when it was not before?

In the BB it looked like this... 
   1) when going into Administration:Forums, selecting an older forum, and then observing the Groups listed, Validating Group should have the 'read attribute' appearing as Red with no checkmark, and it did,
   2) but what it was appearing as for recent forums was greyed out, with a checkmark in the greyed out box (when it should be same as in #1, to be sure).
   3) If I created a group with same attributes as Validating it would demonstrate the Red Highlighting with no checkmark, as it should, in old or new Forums lised in Administration.
   4) But if I edited the existing Validating Group, saved it, and then edited it back to original settings it would still appear greyed out, with a checkmark in there.  (I expected it might 'correct' itself if I edited it, but it did not).
   5) Deleting it and recreating it, as described in my original post, corrected it...

...but so many others are messed up as well, including Guest, Member, Moderator, and, well, I am uncertain yet about Administrator.  And how would I fix those if need be?
So I am trying to figure out just what this problem is and how to globally fix it?
Do you see the problem?  If its, as you say, not table corruption, then what is that exactly??

Okay, well here's what I (can) gather so far...

    Imagecreate commands necessarily take up about (width x height x 5) bytes of memory for processing.  There is no way as yet that I have found for buffering or chunking the memory allocation for this sort of processing, or chunking the process itself.
    What I found I can do is run a 'ini_set' command against the memory_limit only during certain script executions so I do not have to leave the default mem usage settings ridiculously high. 
   What I plan on doing is writing a script/function that will allow for special cases where I wish to allow automatic memory allocation for a specific type of upload.  Later on I think I might script in an option to simply upload certain types of pics, and then only generate thumbnails for those.... so memory allocation management issues may be reduced.
   These seem to be the options available for this sort of thing for now.

BTW, to answer your question, Jansson, I imagine that the reason for using imagecreatetruecolor is that,  because we are not directly uploading the images, but resizing, and thus recreating, the images, ...for certain types of images it thus requires recreating them with truecolor if one wishes to maintain the full-color integrity.  This reasoning seemed pretty 'simply apparent' to me once I read up on it.

   Although I am thinking about rebuilding the uploader at some point to allow for direct uploading (as opposed to image recreation) in certain circumstances, and this would certainly get around certain memory issues, this possibly will not allow for certain other types of control that are available when using php to re-manage (proprietary issues with certain) images.  For anyone reading this, this is something to keep in mind ;^)

Thanks for your input, guys.  I am open to any further news on this subject, should it come around ;^)  I hope others may find this information useful as well.
Cheers,
TwoHawks