**Home.page.ts:**
import { Component } from '@angular/core';
import { CrudService, Usuario } from '../crud.service';
import { DatabaseService } from '../database.service';
import { SQLite, SQLiteObject } from '@ionic-native/sqlite/ngx';
import { Platform, NavController } from '@ionic/angular';
@Component({
selector: 'app-home',
templateUrl: 'home.page.html',
styleUrls: ['home.page.scss'],
})
export class HomePage {
public GetEmail: string;
public GetSenha: string;
GetUsuario: any[] = [];
constructor( private databaseservice: DatabaseService, private Nav: NavController ) {
}
public Logar(){
this.databaseservice.databaseObj.executeSql('SELECT * FROM usuario',[])
.then((res) => {
this.GetUsuario=[];
for(var i = 0; i < res.rows.length; i++){
this.GetUsuario.push({id: res.rows.item(i).id, name: res.rows.item(i).name, senha: res.rows.item(i).senha, email: res.rows.item(i).email})
}
})
for(var i = 0; i < this.GetUsuario.length; i++){
if(this.GetUsuario.email == this.GetEmail && this.GetUsuario[i] == this.GetSenha){
this.Nav.navigateForward('/pagina-principal');
}
}
}
}
**Home:**
<ion-content>
<div id="logo"> <img src="../../assets/123.png" class="img"> </div>
<div>
<ion-item>
<ion-label position="floating">E-mail</ion-label>
<ion-input type="text" [(ngModel)]="GetEmail"></ion-input>
<ion-icon slot="end" name="md-contact" align-self-end></ion-icon>
</ion-item>
<ion-item>
<ion-label position="floating">Senha</ion-label>
<ion-input type="password" [(ngModel)]="GetSenha"></ion-input>
<ion-icon slot="end" name="ios-lock" align-self-end></ion-icon>
</ion-item>
<br>
<ion-button expand="block" class="botao" shape="round" (click)="Logar()">Logar </ion-button>
</div>
<div class="Div2">
<p>Cadastre-se <a href="../cadastro">aqui </a></p>
</div>
</ion-content>
At the risk of sounding overly harsh, this strikes me as a pointless design to pursue further even if it is just a toy educational project. If it’s intended to be distributed, it’s a trainwreck.
You can’t authenticate against an on-device database and have it mean anything. Anybody with access to the device has access to the contents of that database, which brings me to probably the most important thing I’m going to say here: NEVER EVER STORE PASSWORDS IN PLAINTEXT. ANYWHERE. To check if the user entered the correct password, pass it through a hashing algorithm such as bcrypt.
So, to do proper authentication, the data backing the usario
table needs to be on a separate server, not on the device, and the Ionic app should be sending the authentication information (over HTTPS) to that server, receiving something such as a JWT that can be added to further network requests.
If you don’t want to do all that, and all you want is a completely on-device user-switching solution so that multiple people can use the same Ionic app, I would strongly suggest delegating all the security stuff to the underlying OS of the device, and letting its user-switching do all of this.
If you still don’t want to do that, then there isn’t any point in requiring passwords at all, and in fact, having the passwords represents a huge security problem for your users that didn’t previously exist, assuming you’re storing the passwords in plaintext as it appears. Just let the user pick who they want to be from a list.
In any event, I would not suggest spending any further time on this existing design.
Some other things:
Naming conventions are really important:
PascalCase is for classes, not properties.
camelCase is for properties.
getXXX should be a method, not a scalar.
Always prefer let
to var
. Eliminate every use of any
in your code that you possibly can. Always use ===
for comparison, instead of ==
. SELECT *
is lazy and dangerous, because it silently changes meaning if the underlying schema changes. Always spell out explicit column names in queries. Let the database do its job; only retrieve relevant records instead of fetching the entire table and doing the query in application code.
Apart from that, it’s looking good!