Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Auto Disable Password

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

    Auto Disable Password

    Hi,

    Has anyone created a function in their application where a users password can be disabled at a set time based on the user type, e.g. Contractors 3 months / Permanent Staff 12 months. This is to get around people leaving the company and their password remaining active indefinitely.

    I know that Alpha caters for a password change time period, but i am looking for a auto disable and admin only manual enable function.

    I suspect this would have a direct influence on the security settings. Can anyone offer any suggestions on how i might go about achieving this?

    Thanks,

    Denis
    Last edited by den1s; 11-28-2008, 05:33 AM.

    #2
    Re: Auto Disable Password

    How about just removing their login from Security Framework when they depart the company? Then they could not log in. Alternately, you could just change the password.

    If you wanted to effect a change on a calendar schedule, even if you wrote the routine, someone is going to have to go into the system and launch the routine every day to look for people to expire. That or you have to implement a scheduling routine as described elsewhere on this forum.
    Last edited by Steve Wood; 11-28-2008, 12:53 PM. Reason: expanded
    Steve Wood
    See my profile on IADN

    Comment


      #3
      Re: Auto Disable Password

      Steve,

      Unfortunately, the HR department could do with a radical shake up. You dont get to know when people leave... huge company, not very much control.

      I do need to look at a schedule approach, so that passwords expire automatically after a set period. This is the bit i need a bit of help on. I am not that familiar with the security approach. I will contine to search the forum for a guide.

      Denis

      Comment


        #4
        Re: Auto Disable Password

        You could take the easy way out and just check Passwords Expire? in the Security Framework configuration. It defaults to one year, but you can change it to anything. That way the Framework takes care of expiration and walking the user through resetting the password. You don't have to add any code. A consequence is that everyone's password will expire, even the company managers.
        Steve Wood
        See my profile on IADN

        Comment


          #5
          Re: Auto Disable Password

          Thanks Steve,

          The only problem with that approach is the user doesnt actually get locked out. The system just forces them to use a new password after the expiry time. I need them completely locked out after the expiry time, with no option but to contact the admin to get back in.

          You see this is my dilemma.

          Denis

          Comment


            #6
            Re: Auto Disable Password

            My suggestion did not make sense, sorry. Here are some other ideas, pick one and we can focus on that:

            1. A routine that removes Security Framework records X days after they were created. The framework tables do not contain a creation date, so you cannot use the information in those tables to determine when they should be purged. So you have to set a date in your own Users table and work from that.

            2. A routine that leaves the security framework record intact, but still does not allow them to log in based on criteria, such as X days after their record was created or updated. Then purge the security record later if desired.

            For both of the above, you can run the routine manually, or use a scheduler as described elsewhere in the forum. OR you can let the user trigger the event when they attempt to log in. In this case, the security framework record may stay intact forever, BUT when the user attempts to log in, a routine automatically determines their status. If based on criteria, they should be allowed in, they are not challenged. If they should not be let in, the routine triggers 1 or 2 above, and they are sent to a Message page telling them they are not allowed in, and a set of instructions it warranted.

            I used to run security based on number 2 above. I would create a security record, but prohibit login with code on the Login.A5W page and a STATUS field in the Users table.

            Number 2 has some management advantages. Envision a User table field named STATUS. This could read ACTIVE for normal users who can log in, EXPIRED for users who cannot log in, and PURGE for users who cannot login, and you want to purge the security record. Management can look at that if a user calls and says "I should be able to log in". Management could just toggle the EXIPRED back to ACTIVE and their login would work. Or the can toggle it to PURGE and the record will be purged. And you would want to write a LOG record of all of these changes as they happen.
            Steve Wood
            See my profile on IADN

            Comment


              #7
              Re: Auto Disable Password

              Thanks for your time on this one Steve, I will give it a go.

              Denis

              Comment

              Working...
              X