1 2 Previous Next 22 Replies Latest reply on Apr 13, 2017 3:31 PM by Jason Wood

    Need Re-login advice

    jdevans

      I have a solution that has a layout that is heavily dependent on "who did what." It is basically a chronological build-sheet for a piece of hardware. Each step of the build has a Technician sign-off button and field, and also a QA sign-off button and field. The technician button fires a script that makes sure the record isn't locked, makes sure it isn't already holding a value, and finally if the first two conditions are ok, it sets the technician field to Get(AccountName) & Get(Current HostTimestamp).

       

      As for the QA sign-off, it's more complicated. I have to check for several things before placing the Get(AccountName) and Get(CurrentHostTimestamp) in the sign-off field.


      Background...this solution is intended to replace a paper based process. In the paper world, a technician can merely hand the paper to the QA person, who then signs it with a pen, and stamps with a rubber ink stamp.

       

      In this scenario, since it's all on computers, I thought it might be helpful to allow the QA person to do his/her sign-off during the same login session as the Technician. SO, to that end, I have it working up to the point of the signoff for QA. It's the limbo that the Technician is left in after the fact. The end of the QA signoff script is where the Re-login happens. So if re-login is required, it allows the QA person to re-login. But then the user session is now logged in as the QA person. Anything the technician touches from that point forward, his Get(AccountName) will resolve as the QA person, and not the Technician. How to smoothly get the Technician re-logged in as himself?

       

      Ideas?

        • 1. Re: Need Re-login advice
          alecgregory

          The most secure way is for the technician to re-login at the end of the sign-off process. The script can prompt for and manage that.

           

          If you want to automate it a bit more, the technician can enter their password at the start of the sign-off process. This entry can be stored in a local variable and used to automatically log the technician back in after the QA person has logged in to authorize the sign-off.

          1 of 1 people found this helpful
          • 2. Re: Need Re-login advice
            jdevans

            That's a cool idea. I was wondering about a way to grab their info so the re-login after QA would be sort of automatic.

            • 3. Re: Need Re-login advice
              philmodjunk

              It's a bit of a toss up. You are either asking the technician to enter their password an extra time at the start of the process or an extra time at the end. For security reasons, there's no step for getting the current user's password like you can their account name and privilege set.

              1 of 1 people found this helpful
              • 4. Re: Need Re-login advice
                jdevans

                Yes, this whole idea of allowing the QA guy to "borrow" the Technician's session has to have a trade-off somewhere. It's what we get when we go paperless, yet still sign-off on everything..

                 

                Thanks for the help

                 

                I might need to slightly re-arrange the script though, to allow for the second re-login (the one for the Technician) to appear at the correct time. I understand the limitations now though.

                • 5. Re: Need Re-login advice
                  philmodjunk

                  Another option is to not do any re-log in.

                   

                  Just have the QA person enter their name or some sort of unique identifier. This can even be a unique value that looks up their info from a table of user or account names that functions much like a password, but less securely. The user's input can be replaced by bullets and stored in an encrypted or hashed format in the lookup table is such is needed.

                  • 6. Re: Need Re-login advice
                    Jason Wood

                    Does this happen often? It sounds like a lot of tapping at the keyboard even just for the QA.

                     

                    You might want to consider giving QA people a secret "authorization code" that is only used to sign off on things. Then when you click that QA sign-off button, a dialog comes up asking for the authorization code. The QA's name can be looked up in a table or even hard-coded in the script. No Re-login needed. Another benefit is you can make the code numerals only, which makes it a lot easier to type (one hand) when reaching over to use a computer that another person is sitting at.

                     

                    Another option... give the QA person an iPad? I'm not sure about your workflow but if QA is walking around checking work, their iPad could tell them what's ready for there approval so they can follow the app to go to where they're needed.

                    • 7. Re: Need Re-login advice
                      philmodjunk

                      In theory, you could even set this up so that a QA person approves something by swiping an ID card through a bar code or mag stripe reader.

                      • 8. Re: Need Re-login advice
                        Jason Wood

                        We could go on and on... how about this one...

                         

                        Need something QA'd? Press a button on the layout. The on duty QA is notified by SMS. If they reply to the SMS with "ok", it gets marked approved.

                         

                        But seriously, no hardware to buy, and it's hygienic!

                        • 9. Re: Need Re-login advice
                          philmodjunk

                          Rapidly balding QA person tears out hunk of hair and drops it into DNA analyzer....

                          • 10. Re: Need Re-login advice
                            jdevans

                            Yeah, eventually iPads would make a lot of this better. Baby steps. It's going to be mind-blowing when we toss the paper.

                            • 11. Re: Need Re-login advice
                              jdevans

                              With

                              Jason Wood wrote:

                               

                              Does this happen often? It sounds like a lot of tapping at the keyboard even just for the QA.

                               

                              You might want to consider giving QA people a secret "authorization code" that is only used to sign off on things. Then when you click that QA sign-off button, a dialog comes up asking for the authorization code. The QA's name can be looked up in a table or even hard-coded in the script. No Re-login needed. Another benefit is you can make the code numerals only, which makes it a lot easier to type (one hand) when reaching over to use a computer that another person is sitting at.

                               

                              Another option... give the QA person an iPad? I'm not sure about your workflow but if QA is walking around checking work, their iPad could tell them what's ready for there approval so they can follow the app to go to where they're needed.

                              With this idea in mind, is there a way to implement this so that ONLY the individual QA person(s) know what their authorization code is. Hidden even from the [Full Access] user?

                               

                              Reason I ask, I started to implement a PIN number system, and the best I could do was to obscure the PIN number from anyone except the person to whom it belongs. I could still see it as the [Full Access] user, which isn't good.

                               

                              Our general security approach is, I don't want to know the passwords for individual users, I just want to be able to reset them. I make 1st login-change pw mandatory, so that only the user knows his/her pw.

                               

                              I've never waded into the encryption pond before, so this is new stuff to me.

                              • 12. Re: Need Re-login advice
                                jdevans

                                philmodjunk wrote:

                                 

                                Another option is to not do any re-log in.

                                 

                                Just have the QA person enter their name or some sort of unique identifier. This can even be a unique value that looks up their info from a table of user or account names that functions much like a password, but less securely. The user's input can be replaced by bullets and stored in an encrypted or hashed format in the lookup table is such is needed.

                                How is the "replaced by bullets and stored in an encrypted or hashed format in the lookup table" accomplished exactly? Does it require plug-ins?

                                • 13. Re: Need Re-login advice
                                  philmodjunk

                                  Show custom dialog has long had a "bullets" option for an input field.

                                   

                                  FileMaker 15 also adds such an option for any field on your layout. It's the "concealed edit box" format that you can select in place of "drop down list", "pop up menu" or such.

                                   

                                  Here's how passwords are stored by FileMaker and other applications:

                                   

                                  The user sets up their account and specifies the password to use with that account. The application stores a "one way encrypted" version of the password using a hash function. When a user logs in, the password entered is put through the same hash function and the hashed value of the entered password is compared to the hashed password stored for that account. If they match, access is granted. Note that in theory, you can enter something other than the original password to gain access as long as the hash function produces an identical string of characters. The odds of successfully gaining access are very small, but not zero.

                                   

                                  You can do the same for a "password like" identifier used to look up information. GetContainerAttribute can be used with a text field instead of a container field to get a hashed value to use for both storing an encrypted ID and for comparing the plain text version entered by a user to that encrypted ID.

                                   

                                  GetContainerAttribute ( TextField ; "MD5" )

                                   

                                  No plug ins, just native FileMaker. Note that you need at least two input fields, a "user name" that's just the name of the QA person and a concealed edit "ID code" field that they enter to put through the "Match hashed values process". Your code then finds the record with that user name and compares the stored hashed value with the hashed version of the ID code just entered.

                                   

                                  This is should not be used to "roll your own security" for gaining access to your solution, but for the lesser needs here, it's an option to consider.

                                   

                                  And if you have ever wondered why people have been telling you to use hard to guess passwords with a lot of characters and including both upper/lower case along with symbol type characters, that's because hackers try to put the hashed password value through a "rainbow table" that matches the hashed value to a plain text string that can produce that hash code and thus grant them entry. The longer the password, the larger the possible character set, the more insanely large the rainbow table has to be in order to work as a means of looking up a password that produces a matching hash value.

                                  3 of 3 people found this helpful
                                  • 14. Re: Need Re-login advice
                                    jdevans

                                    well, as it's about time to wrap it up and go home for the day, I'll try to get to work on this in the AM> THANKS!! Nice explanation by the way.

                                    1 2 Previous Next