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

Advice on Security and Single Sign On

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

    Advice on Security and Single Sign On

    The nature of our development environment leads us to develop multiple alpha applications for different groups within the same organization. For example, we have a common Alpha application that anyone in the organization can access, then department specific applications. Some administrators can access multiple applications for multiple departments so the combinations are who can access what are somewhat extensive.

    I thought we had this licked, we created a cookie that encrypts userid and password and for each application we read that cookie and auto login the user. However, we have recently discovered a flaw in that approach and have yet to determine the best workaround.

    The new issue relates to a single user opening multiple Alpha Applications (running within IIS and using Alpha IIS Server). When they open application 1, they are logged in. Now they open application 2 (without closing application 1). They are logged into application 2 without issue. However, when they go back to Application 1, that application acts like they are not logged in and redirects them to a login page.

    They can however open Application 1 and are auto logged in. If they do stuff in application 1 and close it then open Application 2, everything works as expected. They get logged in, do stuff and close the application. This can go on indefinitely as long as they open and close a single application. When they try to toggle between multiple applications, then the are logged into the latest application they access and logged out of all other currently open applications.

    Any thoughts on how to get around this or where to look would be greatly appreciated. BTW, these are browser based applications running on a desktop, we do not need to solve this issue for mobile (yet?)..

    Thanks,
    Jeremy

    #2
    Re: Advice on Security and Single Sign On

    No matter what you do for single sign on, you will not be able to run multiple applications in the same browser at the same time. Alpha apps do not work that way.

    Each application has it's own session and each browser can only handle a single session at a time, even if they are in mutiple windows.

    One way you could get around this is opening application 2 in a different browser (ie: Firefox and Chrome), but then you probably lose access to the cookie and can't do single signon that way. You can also run one in Chrome and one in Chrome Inognito. But again, you won't have access to the cookies that way.

    Why are these all different applications? Is there a reason they can't all be within the same application? With proper security setup, people should only have access to their portion of the much larger application.

    But if they must be different apps, then they must be open in different browsers to run them at the same time.

    Comment


      #3
      Re: Advice on Security and Single Sign On

      We have created an app for a client which is similar to your situation, Jeremy, and configured it as Larry suggests. When the user logs on, they are taken to a menu (a list of applications). What is shown on this menu is determined by who signed on. From there, the user uses that "application" (portion of the program) and when they are finished, they go back to the list of apps.

      It works quite well.

      You should try that.
      Jay
      Jay Talbott
      Lexington, KY

      Comment


        #4
        Re: Advice on Security and Single Sign On

        Larry and Jay, thank you for the reply. I like the idea of a single app, I was just concerned that with that approach eventually, I would encounter other issues by having all my eggs in one basket if you know what I mean. I think I'll go down that path and address any issues that arise because the way that things are currently set up has already reached too many limitations.

        Comment


          #5
          Re: Advice on Security and Single Sign On

          Do what they are saying and have an app "launcher". The app launcher checks a table of applications and users and returns the results they have access to. You could control that through a separate admin interface if you want that only your username has access to. when they select an app from the list it opens the new UX in it's own window. By opening the app/ux in it's own window you don't have to have a large component which could hog up memory. It will work if you set up the security right. You could also have a separate group for each app, and then other groups which define rights. You would then assign multiple security groups to each user. Have fun!

          Comment

          Working...
          X