Https and cookies

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Ed762
    Member
    • Jun 2014
    • 43

    Https and cookies

    We put the site under https and have observed a few things that could be related to cookies and session time-out. We have taken a look at this earlier thread:



    This same issue starts popping up after switching over to https and implementing redirect from http to https. It looks like cookies time out abnormally quick after the switch, so people have their unread threads turned to "read" after a few page loads.

    Would like to know if VB can provide us with some ideas as to how to correct this issue.


  • Trevor Hannant
    vBulletin Support
    • Aug 2002
    • 24325
    • 5.7.X

    #2
    Personally I change the thread marking to Database (automatic forum marking) here:

    AdminCP > Settings > Options > General Settings

    Far more accurate...

    Vote for:

    - Admin Settable Paid Subscription Reminder Timeframe (vB6)
    - Add Admin ability to auto-subscribe users to specific channel(s) (vB6)

    Comment

    • Ed762
      Member
      • Jun 2014
      • 43

      #3
      How much more CPU and disk space for this option? Do you have a way to calculate this?

      Comment

      • Paul M
        Former Lead Developer
        vB.Com & vB.Org
        • Sep 2004
        • 9886

        #4
        Insignificant really, and no.

        Database marking is the default in vB4 and has been for quite a while, the cookie system is old, creaky, and best not used.
        Baby, I was born this way

        Comment

        • Ed762
          Member
          • Jun 2014
          • 43

          #5
          Is the count data cleaned up by one of the scheduled tasks on a periodic basis?

          Comment

          • Mark.B
            vBulletin Support
            • Feb 2004
            • 24286
            • 6.0.X

            #6
            What do you mean by the count data? The thread isn't marked either read or unread in the database. Once read, it is only changed back to unread if a new post is made in it. There's no cleaning to be done.

            Database marking is how this should be done. There's no other way to fix your issue. It isn't going to fill your disk or slow your forum.
            MARK.B
            vBulletin Support
            ------------
            My Unofficial vBulletin 6.0.0 Demo: https://www.talknewsuk.com
            My Unofficial vBulletin Cloud Demo: https://www.adminammo.com

            Comment

            • Paul M
              Former Lead Developer
              vB.Com & vB.Org
              • Sep 2004
              • 9886

              #7
              Originally posted by Ed762
              Is the count data cleaned up by one of the scheduled tasks on a periodic basis?
              That depends on what "the count data" is. Please explain what you mean.
              Baby, I was born this way

              Comment

              • Ed762
                Member
                • Jun 2014
                • 43

                #8
                Originally posted by Paul M

                That depends on what "the count data" is. Please explain what you mean.
                If the db is going to flag a thread as read by a specific account, this means there will be a new field related to each account that identities the thread ID that is read by an account.

                It will make sense that this field is cleaned up periodically. There is also no value to mark anything, practically speaking, over a week old.

                Otherwise, there needs to be some calculation of disk space consumption to make sure surprise won't happen a year or 2 down the road. Yes, RAM and disc space are cheap these days...but it is not a good thing to do things without knowing the down stream effect.

                Comment

                • Paul M
                  Former Lead Developer
                  vB.Com & vB.Org
                  • Sep 2004
                  • 9886

                  #9
                  The data is kept in separate table(s) and records older than your set limit are removed by one of the clean-up cron jobs.
                  Baby, I was born this way

                  Comment

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

                    #10
                    The threadread table is made up of three integer fields. So it takes 16 bytes plus overhead for each read thread. Userid, threadid, and date.Miniscule in the long term. All threads older than 10 days (configurable) are considered read and don't have records.

                    So, 10(average_users * average posts) * 16 = maximum bytes of storage in a default system. Not counting MySQL's overhead (indexes, etc...) If it gets above a megabyte on most systems, I would be surprised.
                    Translations provided by Google.

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

                    Comment

                    • Ed762
                      Member
                      • Jun 2014
                      • 43

                      #11
                      Originally posted by Paul M
                      The data is kept in separate table(s) and records older than your set limit are removed by one of the clean-up cron jobs.

                      Which con job will that be? How is that limit set?

                      Comment

                      • Paul M
                        Former Lead Developer
                        vB.Com & vB.Org
                        • Sep 2004
                        • 9886

                        #12
                        It doesnt really matter which one.

                        Why dont you look at the settings yourself in the ACP (General Settings IIRC).
                        Baby, I was born this way

                        Comment

                        widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
                        Working...