Invalid authkey problems in postnuke  Bottom

Go to page 1 - 2 [+1]:

  • Hello Again

    This thread is related to bug report 15830.

    We at daimonin have the same problem and its related to a earlier bug
    report from me and the cache system. For some reasons no dev jumped on it
    (no offence, thats dev life) so i have to point it out:

    The current Postnuke login/authkey/cache logic is simply broken.
    With the current system you have either to decide to disable Smarty or
    don't allow anything which needs an authkey - which is no option.

    The problem itself is pretty simple: pnRender/Smarty is caching the Smarty
    tags - including the < --[ pnsecgenauthkey module="Users" ]-- > and other
    calls where caching is simply a bug.

    With a cached authkey, the user can sometimes login, sometimes he is send
    to a login/authkey loop hole - the effects are different and strange.

    Whatever - the problem is gone when you enclose the call above with a [nocache]
    tag.

    But: There are more tags in the code templates which should never be cached like
    the log/status messages.

    And: We talk about *many* templates, also in non core and extern modules.

    How to solve it? Well, enclose all with [nocache] but thats the worse fix.

    My simple suggestion: Add a pnRender flag which should be enabled on default and
    tells "auto cache system tag" (or reverse).

    When enabled and smarty/pnRender is parsing a file, the parser don't look only for
    [nocache] tags but also for a row of tags like the authkey which should be cached too.

    When the parser finds such a system tag (stupid name, i don't know how to call it) outside
    a [nocache] area it encloses it with a virtually [nocache].

    Thats pretty simple because the whole logic and code for parsing end nocache is already there.

    In that way the whole logic is there, backwards compability is given and we have another system
    module option you guys can then explain over and over in the support thread... icon_wink

    Sounds like an idea, or?



    edited by: michtoen, Feb 29, 2008 - 04:03 PM
  • We are currently discussing the cache feature. There won't be a solution for this in .8 as it is almost complete.

    The future caching mechanism will probably jump in at a lower level (DB) than page caching. Caching of whole page is always a problem.

    --
    best regards from Kiel, sailing city

    Steffen Voss

    Member of the Zikula Steering Committee
    Read The Zikulan's Blog "If you want people to RTFM, make a better FM!"
  • That are BAD news guys...
    The needed code changes should be not that much, this is a fix not a feature.

    I can stress it not enough: Its a broken feature in a critical area.
    Even you browse now through all the delivered templates and change everywhere
    the critical lines by including the nocache (thats some) you have to add some
    serious warnings and docs how to use the critical tags right.

    Not to mention that you will break all the older modules which needs now some handwork
    to make them run proberly.

    You will have here more stress in the support as the 2 hours you need to implement the
    autocache thingy.

    Except you found a workaround i overlooked?

  • It seems that a temporary solution is to enable the pnRender cache *only* and use the respective nocache tags... have to review this point because from my point of view this is a bad thing too...

    Now i know that this topic has been discussed a lot on the core-dev list, and we are playing with caching *because* Smarty offers it, but core-devs didn't select Smarty because of its caching feature, so what would have happened if core-devs chose another template system? no-one would talk about caching... caching on module level should be enough in most cases.

    We'll see if we get more answers for this issue...

    --
    - Mateo T. -
    Mis principios... son mis fines
  • One option may be a quick hack of the authkey plugin. Try adding the following code somewhere into the plugin.

    Code

    $smarty->caching = false;


    This, in theory, will turn off caching for the Smarty instance when this plugin is called.

    -Mark

    --
    Visit My homepage and Zikula themes.
  • Mark,

    will that turn of ALL Smarty caching for the entire pnRender call, or merely for what is returned by the plugin?
  • i've noticed with RC3 some random Invalid authkey (modification are always taken), but pnRender and Theme caching are not enabled

    icon_confused



    edited by: jami, Feb 29, 2008 - 07:40 PM

    --
    http://code.zikula.org/crpcalendar
    http://code.zikula.org/crpvideo
    http://code.zikula.org/crptag
    http://code.zikula.org/crpcasa
    http://jami.cremonapalloza.org
  • I can't see the problem ...

    The caching works fine as far as i can see - the only problem i noticed is, that
    this specific tags must be excluded. Which works fine but should be done
    implicit and not explicit.

    This is not a smarty/pnrender topic nor a module one - its simlpy is wrong setting which
    can you see that it works when you use the nocache tags.

    Where is the problem to tell Smarty to do what its designed for??
    My suggestion was simply to do something smart instead of splatter now all
    templates by a nocache.

    Because the parser change will be pnrender intern you are free to change or
    substitute that in later versions, because here we don't change in the modules
    anything.



    edited by: michtoen, Feb 29, 2008 - 07:06 PM
  • Sry Michtoen. This is something for .81 - It's impossible to release a perfect system with architecual changes as big as the step from .7 to .8. We have already spend years on this release and we can't postpone it again because of features that are not nescessarily needed for running a website.

    --
    best regards from Kiel, sailing city

    Steffen Voss

    Member of the Zikula Steering Committee
    Read The Zikulan's Blog "If you want people to RTFM, make a better FM!"
  • You want release $NewName with a broken cache/login mechanism?

    Honestly... I decided for postnuke mainly because i thought postnuke
    have understand how important a staged cache system is for a always
    extremly slow enviroment like LAMP.

    I am pretty disappointed because i already had brought the Account
    glitches (email of users) to you.

    You spended alot time & code for example for the category system and your core -
    but web 2.0 means not content - it means users. Which ARE your content because
    they create them.

    ATM postnuke is not a modern CMS - you still do the same things like phpnuke did in 2001.
    Inclusive the oversimple and logical broken user handling.

    Just to stress it: We had around 300+ new users in the past. When the new site is established and our
    next version is released which enforce a website login, we assume up to 1000 new users per day.
    Thats not a "we are cool, we have 1000 new users a day" - its a "1000 new users, how in hell we
    can handle that right"?

    A unhacked postnuke is in the current state simply to broken for a website like www.daimonin.com,
    you know that this is a true statement? I really would see that changed, but when
    you guys simply deny the importance of a secure user handling and smooth login system and
    prefer the traditional news/article handling ... Oh well.

    We need a clean user managment of emails & login, which is not in the state of a CMS half a century
    ago.

    Sorry for the hard words. Postnuke is a great system. But if you don't spend a few more days in that
    area you will release something which a major glitch.

    You really want that the first §newname reviews are like "great, old style CMS. But for web 2.0 you have
    to install drupal?".



    edited by: michtoen, Mar 01, 2008 - 03:41 PM
  • I feel like michtoen (but i'm not dissapointed)
    and it seems that some bad choices arise because the time is pressuring. We've spent a lot of months getting the 0.8 release to its current state, and we'll expose to the world without have finished it... that's mediocre.

    I know that we may need the momentum of the 0.8 release, but that momentum can be negative is the package released is not finished. I understand that almost nobody has the time currently to go deep in the cache issue, but if 0.8 will be released with a buggy cache, it's better to hide the cache option in the Themes (Xanthia) Admin Panel (supposing that the pnRender cache works Ok in some way)...

    ValueAddons modules needs some attention and i'm full on that, but it needs some days until finish that work... like people says here (something like):

    "We have already waited the long part, we can wait the least"
    IMO we can wait and work HARD some days more

    P/S: I guess that if core-devs wants to release the v0.8 Today
    a pre-announcement is needed in the community
    one week of full work and expectation,
    and also to coordinate the release with local communities!

    --
    - Mateo T. -
    Mis principios... son mis fines
  • No, the xanthia cache works fine so far... The problem is pnRender which caches
    the authkey. There are some options to solve that as i described. Really, it works
    fine on our site with many users login in and out when you capsule the authkey with
    nocache. Just - why splattering the templates with it when a handful lines of code
    can solve the whole issue?




    edited by: michtoen, Mar 01, 2008 - 05:45 PM
  • as far as I can see it, they are working on the issue.

    --
    best regards from Kiel, sailing city

    Steffen Voss

    Member of the Zikula Steering Committee
    Read The Zikulan's Blog "If you want people to RTFM, make a better FM!"
  • The core needs to address this, as there is no good reason for templates to have to make it work correctly. Authentication is not part of the presentation level, no exceptions, in my opinion.

    People evaluating the system will be annoyed, if they have authentication failure. One can argue that the system is doing as it is designed to do, but to a lay user or a user with inexperience with the system it is just __________.

    It is simply silly to go and have to encapsulate every tag with other tags if they do not extend the logic.

    Obviously there are something that should never be cached (or cached long term). Sure it may make sense to cache auth (and others) for very short periods in busy servers.

    I really do not want to explain to people they are getting locked out of there systems is a design feature and not a bug. Normally, I support the 'logic' that is given to me by team, but not this time. But of course all and all, I am very pleased with the system. I am just advocating for my people in the trenches. :)

    I am not on deadline for .8 compliance, but I would invite most webmaster to start there conversions who have confidence of there skills. It is not a scary upgrade, but it is not as simple as .76x to a .76x upgrade either. Consider your third party modules, is my best advice. I have one site, I am going to have to 'do something'... and another that will take a few hours to make me happy with it. Otherwise I am good to go.

    Happy PostNuking.



    --
    David Pahl
    Zikula Support Team
  • Let's focus on the specific instance of the login screen and see if we can't solve this. Can you try the following... Change line 59 of system\Users\pnuser.php from

    Code

    $pnRender = pnRender::getInstance('Users');

    to

    Code

    $pnRender = pnRender::getInstance('Users', false);


    This will not then cache the login screen output (for pnRender caching anyway....).

    -Mark

    --
    Visit My homepage and Zikula themes.

Go to page 1 - 2 [+1]:

This list is based on users active over the last 60 minutes.