Announcement

Collapse
No announcement yet.

SC Security Model: Is it best practice?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • SC Security Model: Is it best practice?

    The default generated log-in security app basically loads up an multidimensional array per logged in user for all the individual app rights. Looking into View --> Data in Session shows a massive amount of data stored into the servers memory. I can imagine the implications for a large number of logged on users and large number of applications.

    Has anyone tried loading up rights in the Init event each time an app is accessed? Would this break the Security functionality? Is there a more efficient way of achieving the objective as opposed to loading such large arrays upfront?

  • #2
    why you care if it will store a lot of data in servers memory?! maximize your resources and let the server take this part off you. playing with security module (unless you know what you are doing) is not really recommended, a lot of things are linked to the functionality of that "data" which is stored and ready to reply user/app requests.

    but I recommend is to re-innovate the security module with different kind of password hashing and less errors based on many reviews and feedback of users, but, again, this one is by SC, which is a lost cause
    Last edited by MikeDE; 02-27-2015, 05:38 AM.

    Comment


    • #3
      The alternative would be to check for rights on each and every action by looking into the database causing a lot of extra database access. Would slow down your application significantly.
      Albert Drent
      aducom software netherlands
      scriptcase partner, reseller, support and (turn-key) development
      www.scriptcase.eu / www.scriptcase.nl

      Comment


      • #4
        Scriptcaser,

        You can turn on "Save Session Data in Database" which will do exactly what it says.

        This is commonly used when you are load sharing between two web servers that are sharing the same database. When you click on a button at the browser, and you possibly get directed to web server B instead of web server A, the session variables can still be gotten from the database.

        The slowdown that you may encounter is virtually unnoticable as long as you have good connectivity between the web server and the sql server.

        We use this approach on our web server clusters, and response is great. We also load balance our sql servers so that we have automatic fail over.

        Dave
        Dave Prue
        Code Whisperer
        Lahar International Corp
        www.lahar.net

        Comment


        • #5
          Originally posted by daveprue View Post
          You can turn on "Save Session Data in Database" which will do exactly what it says.
          I wanted to know this long time ago what other consequences may have? will it make the db bigger size? will those variables be erased when session is timeout or the user logout or close the browser? what you think Dave is it better?

          Comment


          • #6
            Mike,

            I like it very much. If you think about it, the way that session variables are normally kept on a web server, they are stored in a session file. When you access them, they are read into memory. When you update a session variable (write to a ScriptCase global variable) the file is updated. The file lives until session expiration at which time the session file is deleted. How much more overhead can there possibly be if, instead of a file managed by Apache/PHP, the data is stored in a database managed by MySQL? If Apache/PHP and MySQL are running on the same server, many people say that MySQL access of session data is faster than Apache/PHP's.

            So next question would be "how about if the SQL server is on a different machine than the web server". That is my case. Between servers I have a 100MBit ethernet backchannel, and you absolutely cannot notice any difference in speed, session in database or session in files.

            In terms of how long the data lives in the database, the data is deleted upon expiration of the session. That is defined as 'some configurable period' without any writes to a session variable. You also can manipulate the session via PHP functions - kill a session, start a new session, etc. But the timeout, say 15 minutes, gets reset every time a session variable (i.e. scriptcase global variable) gets modified. So, if you close your browser without logging out, the session will disappear off the server 15 minutes after the last session variable was written to. Remember, web servers are stateless. They have no idea that you have closed your browser. This is the same as the timeout that you sometimes experience in ScriptCase Development Mode.

            In my environment, it is very important to us to have a scalable server farm. If our users go from 2,000 to 20,000 unexpectedly, we need to be able to scale quickly and easily. As a result, MySQL runs on 2 dedicated servers. They are configured for master-master replication so you can access either one and get exactly the same data. Also, either one can die without anything being adversely affected. I run a HA-Proxy front end that balances the load between the two sql servers. I can add more MySQL servers as I may need to, very easily (even in geographically different places). Takes minutes, not hours to bring a new one online. Likewise, I have two web servers, both running identical production copies. Again, the load is balanced to direct queries to the least busy server. I can add more servers whenever I like, and either one can die without affecting anything else. As a matter of fact, I can have either web server die at the same time as either sql server, and the web site is still up - this is called "High Availability". Because of storing the session data in database, if you are on web server A and it dies suddenly, your next page access will come from web server B and the user will never even know it. If the Web servers were storing the session data in a local file instead of the database, then the session would be lost when the web server died and the user would have to log in again and begin a new session on the other web server.

            So yes, I like sessions being stored in database. In all of our testing, there is no noticeable slowdown, and it enables us to do many things that improve the responsiveness, robustness, and metrics of the overall system.

            Sorry for the long winded explanation, but we have spent many hundreds of engineer hours analyzing performance & resilience metrics and refining our ideal scalable cluster. I guess I am like a proud papa describing my daughter's school performance.

            Dave
            Last edited by daveprue; 02-27-2015, 11:56 AM.
            Dave Prue
            Code Whisperer
            Lahar International Corp
            www.lahar.net

            Comment


            • #7
              Sorry for the long winded explanation, but we have spent many hundreds of engineer hours analyzing performance & resilience metrics and refining our ideal scalable cluster. I guess I am like a proud papa describing my daughter's school performance.
              Nothing wrong with that, tnx for the explanation. We have tests like these on our list for a long time, so it's worth looking at the experiences of others.
              Albert Drent
              aducom software netherlands
              scriptcase partner, reseller, support and (turn-key) development
              www.scriptcase.eu / www.scriptcase.nl

              Comment


              • #8
                I see what you mean and understand your point uncle Dave

                It is really a debatable thing again, and another matter of positives and negatives huh I see

                We admire your nice way of explanation and how you putting it all straight forward for everybody to learn, as Albert said, it is always nice to have a look at other people experience.

                Once more, thanks a lot for your time and the decent way of explaining the idea... you reminded me of the way that Albert explains something, so direct to the point and simplifying the tough stuff, just like earlier today I was watching old webinar for Albert about paypal (I wondered how I didn't see it before!!) he kept saying it is simple, rr says LDAP is simple, all that code albert scrolling down 2km of code it is simple loooooooool guys you are so helpful in facing hard times making things feel easier and more fun

                Comment


                • #9
                  I am really looking forward to someday when NetMake sees fit to host a ScriptCase Developers Conference, we can all meet face to face.

                  Dave
                  Dave Prue
                  Code Whisperer
                  Lahar International Corp
                  www.lahar.net

                  Comment


                  • #10
                    Originally posted by daveprue View Post
                    I am really looking forward to someday when NetMake sees fit to host a ScriptCase Developers Conference, we can all meet face to face.

                    Dave
                    we are looking to organize one here in Spain. We have good food and good weather
                    /Giuseppe

                    Professional Scriptcase Services
                    Some Customers opinions

                    Comment


                    • #11
                      Sign me in.

                      Comment


                      • #12
                        Well I like good food and good weather. Forget SC and let's go to the beach.
                        Albert Drent
                        aducom software netherlands
                        scriptcase partner, reseller, support and (turn-key) development
                        www.scriptcase.eu / www.scriptcase.nl

                        Comment


                        • #13
                          Originally posted by aducom View Post
                          Well I like good food and good weather. Forget SC and let's go to the beach.
                          Albert, Jelly fish are there, forget the beach, lets focus on food and good weather.

                          Sign him in Giu, he will come. rr will come too.

                          Comment


                          • #14
                            Beaches don't excite me.

                            We have 7107 islands here, it's hard to buy land that is not beachfront.
                            Last edited by daveprue; 03-02-2015, 04:18 AM.
                            Dave Prue
                            Code Whisperer
                            Lahar International Corp
                            www.lahar.net

                            Comment


                            • #15
                              Ok Dave is coming too, sign him in Giu. Food and weather Dave, food and weather.

                              Comment

                              Working...
                              X