Member Avatar for jamie.choi.1806

I think this could be put at Web Design part, but maybe the JavaScript is more important
I am reposting this at Web Design
I posted it at JavaScript Forum, that was a mistake

Code:

<script src="//code.jquery.com/jquery-1.9.1.min.js"></script>

<!--
  Simple Login Form
  ** Used with jQuery
-->

<form id='login'>
  <input type='text'     placeholder='username' id='login_name' />
  <input type='password' placeholder='password' id='login_pwd' />
  <input type='submit'   value='Login' />
</form>

<script>
  var logins = [
    ['login', 'pwd']
  ];

  $('#login').submit(function(e) {
    e.preventDefault();

    for(login in logins) {
      if($('#login_name').val() == login[0] && $('#login_pwd').val() == login[1]) {
        loginSuccess();
      }
    }
  });

  function loginSuccess() {
    // If successfully logged in this function will be called

    // Run some function here
  }
</script>

Demo: JSBIN

  • 3 Contributors
  • 2 Replies
  • 209 Views
  • 1 Hour Discussion Span
  • Latest Post Latest Post by toxicandy

Dani AI

Generated

Short expert note for , and :

The pattern shown is fine for a quick demo but is unsafe for any real users. As pointed out, credentials placed in client-side code are visible and trivially copied. As asked, you need to decide whether this is a learning toy or real auth — the implementation and risks differ hugely.

Two immediate fixes and a bug note:

  • Logic bug: iterating an array with for ... in yields keys, not elements. Use an element-based loop or destructuring instead, for example:
    for (const [u,p] of logins) {
if (username === u && password === p) { loginSuccess(); break; }
}
  • If this is a production login, remove all credential checks from the browser. Never ship plaintext passwords or account lists in client code.

Recommended minimal secure flow (practical checklist):

  1. Serve the site over HTTPS only.
  2. Send credentials to a server endpoint via POST.
  3. On the server, look up the user and compare the submitted password to a stored salted hash (bcrypt or argon2).
  4. On success create a server-side session or issue a short-lived access token; set cookies with HttpOnly, Secure and appropriate SameSite.
  5. Add rate limiting, account lockout after repeated failures, input validation, and protect against CSRF.
  6. Store user records in a database using parameterized queries or an ORM to avoid injection risks.

If you only need an offline prototype, clearly label it "demo only" and keep test accounts isolated. Use browser devtools to inspect network traffic and cookies when testing so you can verify HTTPS and proper cookie flags.

Recommended Answers

All 2 Replies

Member Avatar for JohnnyT

Your username/password would be visible in the source of the page though would they not? This would be a big security concern. :-)

Member Avatar for toxicandy

Is this just for testing or learning about JS? Login pages should not be done in JS, it's all client side, how are you storing values to retrive login information of past users. What's the whole purpose of this site?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.