vB-5.3.4 PL1: email notification jobs running sometimes only

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • m97forum
    Member
    • Jun 2017
    • 54
    • 5.3.x

    #16
    Hallo again,

    I just played a bit:

    Actually, I'm getting the following stacktrace (line numbers may be incorrect, I added debugging statements):

    #0 /kunden/153079_80335/webseiten/core/vb/api/content.php(429): vB_Api_Content->getFullContent('40540', false)
    #1 /kunden/153079_80335/webseiten/core/includes/functions_digest.php(189): vB_Api_Content->getContent('40540')
    #2 /kunden/153079_80335/webseiten/core/includes/cron/digestdaily.php(29): exec_digest(2)
    #3 /kunden/153079_80335/webseiten/core/includes/functions_cron.php(248): include_once('/kunden/153079_...')
    #4 /kunden/153079_80335/webseiten/core/vb/api/cron.php(34): exec_cron()
    #5 [internal function]: vB_Api_Cron->run()
    #6 /kunden/153079_80335/webseiten/core/vb/api/wrapper.php(199): call_user_func_array(Array, Array)
    #7 /kunden/153079_80335/vbcron-abs.php(38): vB_Api_Wrapper->__call('run', Array)
    #8 /kunden/153079_80335/vbcron-abs.php(38): vB_Api_Wrapper->run()
    #9 {main}

    Since the call to the validate function (which on content.php(445)) does not provide a userid, the validate function uses the session's userid. I assume(!) that this is a guest's userid, since this entire call is launched by the scheduled tasks.
    Now, I changed functions_digest.php(189) such that it hands over the following parameters to content.php(429):
    1. $post['nodeid'] (unchanged)
    2. false (default of the pre-existing permissions parameter)
    3. $post['userid'] (the new one): this is the userid of the user who is get the email

    The nodeid and userid gets handed over to the validate function.
    Result: it works

    I'm now having trouble creating the Array functions_digest.php(191). Sorry guys, but have you ever tested this thing?

    Thanks.
    Stefan

    Comment

    • m97forum
      Member
      • Jun 2017
      • 54
      • 5.3.x

      #17
      Hello again (last time tonight, I promise),

      I managed to get around some of that latest Array-trouble. Actually, it was that same validate error again. No userid provided? Let's take the session's userid = 0 and BENG! Stacktrace:

      #0 /kunden/153079_80335/webseiten/core/vb5/route.php(1165): vB5_Route_Conversation->__construct(Array, Array, '', '')
      #1 /kunden/153079_80335/webseiten/core/includes/functions_digest.php(191): vB5_Route::buildUrl('84|bburl', Array)
      #2 /kunden/153079_80335/webseiten/core/includes/cron/digestdaily.php(28): exec_digest(2)
      #3 /kunden/153079_80335/webseiten/core/includes/functions_cron.php(248): include_once('/kunden/153079_...')
      #4 /kunden/153079_80335/webseiten/core/vb/api/cron.php(34): exec_cron()
      #5 [internal function]: vB_Api_Cron->run()
      #6 /kunden/153079_80335/webseiten/core/vb/api/wrapper.php(199): call_user_func_array(Array, Array)
      #7 /kunden/153079_80335/vbcron-rel.php(38): vB_Api_Wrapper->__call('run', Array)
      #8 /kunden/153079_80335/vbcron-rel.php(38): vB_Api_Wrapper->run()
      #9 {main}

      I altered some of files, such that it would provide the userid (the same from above) to that validate function in conversation.php(115). It would work then, but crash the next, because this seems to rerun itself:

      #0 /kunden/153079_80335/webseiten/core/vb5/route.php(1165): vB5_Route_Channel->__construct(Array, Array, '', '', NULL, '')
      #1 /kunden/153079_80335/webseiten/core/vb5/route/conversation.php(200): vB5_Route::buildUrl('83')
      #2 /kunden/153079_80335/webseiten/core/vb5/route/conversation.php(385): vB5_Route_Conversation::getChannelURL(23, Array)
      #3 /kunden/153079_80335/webseiten/core/vb5/route.php(423): vB5_Route_Conversation->getUrl()
      #4 /kunden/153079_80335/webseiten/core/vb5/route/conversation.php(133): vB5_Route->getFullUrl('fullurl')
      #5 /kunden/153079_80335/webseiten/core/vb5/route.php(1165): vB5_Route_Conversation->__construct(Array, Array, '', 'bb', '1874', 'bb')
      #6 /kunden/153079_80335/webseiten/core/includes/functions_digest.php(191): vB5_Route::buildUrl('84|bburl', Array, Array, 'bb', '1874')
      #7 /kunden/153079_80335/webseiten/core/includes/cron/digestdaily.php(29): exec_digest(2)
      #8 /kunden/153079_80335/webseiten/core/includes/functions_cron.php(248): include_once('/kunden/153079_...')
      #9 /kunden/153079_80335/webseiten/core/vb/api/cron.php(34): exec_cron()
      #10 [internal function]: vB_Api_Cron->run()
      #11 /kunden/153079_80335/webseiten/core/vb/api/wrapper.php(199): call_user_func_array(Array, Array)
      #12 /kunden/153079_80335/vbcron-abs.php(38): vB_Api_Wrapper->__call('run', Array)
      #13 /kunden/153079_80335/vbcron-abs.php(38): vB_Api_Wrapper->run()
      #14 {main}

      1. I cannot provide the userid here anymore, it's just getting too complicated
      2. the seems to be an endless loop --- maybe there is some abortiing condition, but I dont see it

      Please have a check here - it's quite frustrating to follow all those leads. And I'm not even sure, if I'm not completely wrong...

      Stefan

      Comment

      • m97forum
        Member
        • Jun 2017
        • 54
        • 5.3.x

        #18
        Hello,

        alright, having given some thought on this one, I'ld like to sum it up:

        The general conception is, that any request in done within the context of the current user. That makes sense for the human-interacted activity.
        The cron-digests are different. Here, the cron acts as a surrogate for the user. Therefore, this session's context is not a valid reference for security checks, since it depends on the user to receive the email whose privileges are to be applied for a security check.

        That is why the jobs initiated by the administrative user always works w/o any trouble, since this admin user has all the privileges to access any forum regardless of the current settings for the user to receive the mail in question.
        It also makes sense, that the cron initiated digest works seamless when public forums are involved, only. Any user may access it, so no security check blocks access.

        Hence, this bug is not about missing something, but it is a conceptional design error.

        Since the code is just the way it is, the question now arises, what to do to get this one going w/o having to change too much (I searched for references to buildUrl-cycle from above and I found roughly 200 ... ). Basically you can extend the existing functions to provide another optional parameter with default value null. But that gets tricky, since there are a couple another default values in the function's declaration. But I cannot come up with a solution for this, since I too depend on the vBulletin distribution and would get out of the version cycle upon changing files locally.

        So, now it's your turn - it's been lying around for 4 years, time to solve it, don't you think?

        Thanks.

        Stefan

        Comment

        • m97forum
          Member
          • Jun 2017
          • 54
          • 5.3.x

          #19
          Hi there,

          alright, I've got it working now. I created the patch attached here, so you can see all the changes I made in order to get this working.
          At least right now, it works on (my machine ) vB-5.4.0, I haven't tried it on vB-5.4.1 yet.
          There is also no guarantee whatsoever that this is working as expected, especially, since it has one bug: it uses the forum's subscriber for the security check, not the one's who is about to to receive the info mail (functions-digest.php(303, 341, 344)).

          Any comments are welcome.

          Please rename the file to .patch in order to use it.

          Stefan
          Attached Files
          Last edited by m97forum; Sun 8 Apr '18, 9:35pm.

          Comment

          • Wayne Luke
            vBulletin Technical Support Lead
            • Aug 2000
            • 73981

            #20
            Use the vbcron.php file included in the do_not_upload folder. It does not utilize a "User Context."
            Translations provided by Google.

            Wayne Luke
            The Rabid Badger - a vBulletin Cloud demonstration site.
            vBulletin 5 API

            Comment

            • m97forum
              Member
              • Jun 2017
              • 54
              • 5.3.x

              #21
              Hey Wayne,

              I'm using vbcron.php from the do_not_upload-folder. And I'm sure of that, since I disabled vB using "normal" user interaction on the site for cron-like acitivities. It therefore relies on vbcron.php only.

              Besides, the scripts called use a user context when running the validate function, which seems to be set to userid = 0 (which seems to be a guest account). I wouldn't have digged into this if it had worked immediately...
              Or is there any way to setup the script to use an user context other than userid = 0?

              Stefan

              Edit: I did not get any email concerning your reply, although I've subscribed to this thread....

              Comment

              • m97forum
                Member
                • Jun 2017
                • 54
                • 5.3.x

                #22
                Hello again,

                yesterday, I updated my changes and they now seem to work properly. I've changed the usercontext usage to run the security check for the user to receive the email - not for the user running the cronjob.

                Note: in order to upload the file, I had to rename it from .patch to .txt
                Note: files reside in folder vBulletin-Code/upload, please adjust before applying the patch

                Thanks
                Stefan
                Attached Files

                Comment

                • Wayne Luke
                  vBulletin Technical Support Lead
                  • Aug 2000
                  • 73981

                  #23
                  We've determined that the patch included above can be a security risk. We've rewritten the functionality and applied a proper fix as well as some enhancements to the Scheduled Task system. These changes should be available in the next version (5.5.1) unless further issues are found. When you upgrade to that version, you should not reapply the patch.
                  Translations provided by Google.

                  Wayne Luke
                  The Rabid Badger - a vBulletin Cloud demonstration site.
                  vBulletin 5 API

                  Comment

                  Related Topics

                  Collapse

                  Working...