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

is it just me? ( SECURITY WEBUSERS )

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

    is it just me? ( SECURITY WEBUSERS )

    Hello all ,
    I simply have question ,
    why would a login component change all users in WebSecurityTables if they have SAME GUID ??? ( MySql Table )


    i am registering users from page A , on submit button i insert the values to WebSecurityTable ( no issue here ) as i am using same encryption in the security Configration .

    so i am giving all the registerd users same GUID and insert them to WebSecurityTable .
    there is no problem with that

    but when for example [email protected] submitted his information and its been stored in the table .
    and then [email protected] also register after [email protected]

    and tried to login using combonent , then all the users in WebSecurityUsers will change to [email protected]

    why would a login change values in the table ??
    i am pulling my hair out from this issue ,
    is it bug ?

    most appreciation if you have anything to comment about this .


    the code which am storing to WebSecurityTable from register page as following

    dim x as C = a5_encrypt_string(e.DataSubmitted.USERPASSWORD,"654321123") <<< Same used encryption number in the login configration of alpha
    dim conn as SQL::Connection
    dim connString as C = "{A5API=MySQL,Server='localhost',Port='3306',UserName='root',Password=':A5:B64:QEBVVEwwMEsxMjMzMjFAQA==',Database='sms'}"
    'dim insert as C = "Insert into websecurityusers (Guid, Userid, Password, Rememberme, Redirpage, Passent,Passexp, Email, Secques,Secans, Updweb,Updlocal,Ulink) VALUES ('"+e.DataSubmitted.USERGUID+"','"+e.DataSubmitted.USERNAME+"', '"+x+"','1','"+e.DataSubmitted.Redirect_Page+"', '2017-01-01', '2017-01-01','"+e.DataSubmitted.E_MAIL+"', 'Secques', 'secans', '2017-01-01','2017-01-01','Ulink')"
    dim update as C = "update websecurityusers set Guid = '"+e.DataSubmitted.USERGUID+"', Redirpage = '"+e.DataSubmitted.Redirect_Page+"' where Userid = '"+e.DataSubmitted.USERNAME+"'"




    but again the code is not an issue , the issue is when the last created user log , all the previous users will have same of his ID .


    >.<

    Regards
    To live anywhere in the world today and be against equality because of race or color is like living in Alaska and being against snow.�

    - William Faulkner

    #2
    Re: alpha anywhere bug ? or is it just me ( SECURITY WEBUSERS )

    up !!


    is it a bug in alpha anywhere
    ????
    To live anywhere in the world today and be against equality because of race or color is like living in Alaska and being against snow.�

    - William Faulkner

    Comment


      #3
      Re: alpha anywhere bug ? or is it just me ( SECURITY WEBUSERS )

      The "guid"field in the security is the token to identify a user, basically the primary key. Since it is used to find / edit a record, it must be unique for every security record. In the same way, the userid must also be unique.

      Comment


        #4
        Re: alpha anywhere bug ? or is it just me ( SECURITY WEBUSERS )

        Originally posted by JerryBrightbill View Post
        The "guid"field in the security is the token to identify a user, basically the primary key. Since it is used to find / edit a record, it must be unique for every security record. In the same way, the user id must also be unique.
        thats a great i got that and i totally understand it ... but again why a login component would change values in table ??
        that should not happen cus logging is suppose to read from table , validate entries and login to next page
        it should not change values ...
        how is that possible .. are u agreeing on that ?
        To live anywhere in the world today and be against equality because of race or color is like living in Alaska and being against snow.�

        - William Faulkner

        Comment


          #5
          Re: alpha anywhere bug ? or is it just me ( SECURITY WEBUSERS )

          Why would you assign the same GUID to every user?
          so i am giving all the registered users same GUID and insert them to WebSecurityTable .
          and THEN expect the records to not point to the same user? I do not understand the acronym GUID stands for Globally Unique...something isn't right here...
          the reason things are changing is that you are assigning the SAME unique ID to all of the users...

          Also I think you should be much more specific as to what values are changing - what fields.
          NWCOPRO: Nuisance Wildlife Control Software My Application: http://www.nwcopro.com "Without forgetting, we would have no memory at all...now what was I saying?"

          Comment


            #6
            Re: is it just me? ( SECURITY WEBUSERS )

            i am assigning serial to guid fields now and its working all good .

            problem resolved ... thanks Charles and Jerry .
            i thought the GuID is related to the group table and its kind of link between group table and user id ... now things are cleared and all working as expected .
            although , i still think that login should not change value in the user table .. as you said Charles , " Expect the records not to point to same user ? "
            pointing is something and changing all other user id to same value is something else .

            anyways , thanks alot again as your posts helped me to resolve my issue .
            GG all
            To live anywhere in the world today and be against equality because of race or color is like living in Alaska and being against snow.�

            - William Faulkner

            Comment


              #7
              Re: is it just me? ( SECURITY WEBUSERS )

              No actually, the issue is still the same issue. What you are essentially doing is affecting every user with that GUID and thats why they were all changing.
              In security there are groups and users, the GUID is a pointer to ONE record typically - unless you have others with the same GUID then it wold be true that it points to a group - BUT the typically use case for a GUID is to point to ONE single unique record.

              I am certain that if you keep at it you will fully understand the relationships in the security tables.
              Cheers
              NWCOPRO: Nuisance Wildlife Control Software My Application: http://www.nwcopro.com "Without forgetting, we would have no memory at all...now what was I saying?"

              Comment

              Working...
              X