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



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

desktop routine to create a web user

  • Filter
  • Time
  • Show
Clear All
new posts

  • desktop routine to create a web user

    I want to write a desktop routine to create a web user. I see that some functions like A5WS_Get_Users() run on the desktop. Instead of reinventing the wheel, has anyone done this already? The tutorials related to creating web users refer to a web application but I want to run this on the desktop. Ideally it would retrieve the websecurity_users table from the a5webroot, and then take in (via xdialog?) the new userid, ulink, password and groups and then update the websecurity_users table in the default.webproject and publish this to the a5webroot. My database and application files are in a directory on the same drive as the a5webroot. By the way, I see that the websecurity_users.dbf file in the default.webproject is identical to the published version in the a5webroot so I assume a simple copy would suffice instead of the retrieval and publishing.
    I know that A5WS_OpenWebSecurity() will run on the desktop but I want a bullet proof one step process.
    Any help would be appreciated.

  • #2
    Re: desktop routine to create a web user

    I did not test this with security but there is a feature pack you can run grid in the desktop so I assume it also work for Alpha Security.
    Maybe there is a better and easier solution, but grid on the using the feature desktop work aa a charme for my use.


    • #3
      Re: desktop routine to create a web user

      Thanks Eric
      Does that feature pack- running grid components in a desktop app - work for version 9? I thought it was only for version 10+


      • #4
        Re: desktop routine to create a web user

        Originally posted by irwincohen View Post
        I want to write a desktop routine to create a web user.
        So if I think this right Web user security in handled in Was (Alpha Five Server). So to take andvance of this feature you have to have WAS running somewhere.

        If so you could use supercontrol: Web Content ( I suppose it will be a hard job).



        • #5
          Re: desktop routine to create a web user

          Hi Ken, I do have the WAS running. In fact both the desktop lan app and the web server are running on the same server. But lan users do not use the web apps and vice versa. But a desktop lan app would have access to the a5webroot directory.


          • #6
            Re: desktop routine to create a web user

            Originally posted by irwincohen View Post
            Thanks Eric
            Does that feature pack- running grid components in a desktop app - work for version 9? I thought it was only for version 10+
            No, you need V10.5 plus the feature pack


            • #7
              Re: desktop routine to create a web user

              My database has a web interface and a desktop interface in the office. I want the office staff to add web users but the office staff does not use the web interface.
              I have written a routine to add a web user from a desktop (not the web) application. Because this is undocumented I am anxious to know if anybody sees any danger in what I am doing.
              The application directory for the project (C:\a5v9\work\work.webprojects\default.webproject) and the directory for the project webroot (c:\a5webroot\work) are always on the same drive on the same computer. I check to see on what drive I am working (for the file copy later).
              The users are allowed to change their passwords online. The files websecurity_users.dbf, websecurity_members.dbf and websecurity_groups.dbf are found in both locations and always seem to be identical after publication or retrieval of the security files. I added the files websecurity_users.dbf, websecurity_members.dbf and websecurity_groups.dbf in the application directory (not the webroot) to the database. First I copy the 3 files from the webroot to the application directory. I search websecurity_users.dbf to be sure the new user is not already a web user. I enter a new record in websecurity_users.dbf and get a guid = alltrim(STRITRAN(API_UUIDCREATE(), "-" , "")). I fill in the fields Guid, Userid, Passent, Updlocal, Password and Ulink in the table. I copy the group guid from websecurity_groups.dbf and enter it with the guid for the user into a new record in websecurity_members.dbf. Then I close the files and copy the three files back to the project in the webroot from the application directory.
              Does anyone see any problem with my direct manipulation of the web security files this way?
              Thanks for reading this.


              • #8
                Re: desktop routine to create a web user

                Sounds plausable to me...if it works. Why do you copy the files back & forth rather than access them directly in the web root - are you not using xbasic (i.e. manual data entry)? Maybe Steve Wood will chime in here? He's the security expert.
                AlphaBase Solutions, LLC

                [email protected]


                • #9
                  Re: desktop routine to create a web user

                  Thanks Peter, I copy the files back and forth because I have to add the web security files to the database in order to add a record for the new user. The catch is, that the drive for the entire project changes. On my development machine everything is on C: but on the application server everything is on D: But since the security files are in a subdirectory of the database; (webprojects, default project) I do not have to specify the drive in the path when I add them to the database. If I added the files from the web root I would have to specify the full path including the drive and that can not be known when I add the files to the database. But for the copy I do use xbasic to find out what drive I am working on and that can be done at run time. So I have to make the changes in the database subdirectory and copy them to the webroot. I start with a copy from the web root in case a user has changed a password. The whole thing is in xbasic in a button on-click event. It does seem to be working in testing. I just put it in production and a little concerned about the long term effects because it is undocumented. But I am optimistic.
                  Thanks for your reply.