›

(Réglé) Traitement d'une requête très long (presque 20 secondes)

24

Réponses

  • Ben77650Ben77650 Membre
    mai 2014 modifié #32

    AliGator je viens de penser à  un truc ma requête synchrone est posté dans le 1er message de ce sujet

     



    
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
    
{
    
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    
    if (self) {
    
        self.title=@Mon compte;
    
    }
    
    
    
    loadingView = [[UIView alloc] initWithFrame:CGRectMake(75, 200, 170, 170)];
    
    loadingView.backgroundColor = [UIColor colorWithRed:0 green:0 blue:0 alpha:0.5];
    
    loadingView.clipsToBounds = YES;
    
    loadingView.layer.cornerRadius = 10.0;
    
    
    
    actview = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge];
    
    actview.frame = CGRectMake(65, 20, actview.bounds.size.width, actview.bounds.size.height);
    
    [loadingView addSubview:actview];
    
    
    
    loadingLabel = [[UILabel alloc] initWithFrame:CGRectMake(20, 80, 140, 22)];
    
    loadingLabel.backgroundColor = [UIColor clearColor];
    
    loadingLabel.textColor = [UIColor whiteColor];
    
    loadingLabel.adjustsFontSizeToFitWidth = YES;
    
    loadingLabel.text = @Récupération de vos données. Veuillez patientez svp...;
    
    loadingLabel.lineBreakMode = NSLineBreakByWordWrapping;
    
    loadingLabel.numberOfLines=0;
    
    loadingLabel.textAlignment = NSTextAlignmentCenter;
    
    [loadingLabel sizeToFit];
    
    [loadingView addSubview:loadingLabel];
    
    [self.view addSubview:loadingView];
    
    [actview startAnimating];
    

    
    
    
    [self getMemberInfo];
    
    
    
    return self;
    
}
    

    
-(void)getMemberInfo
    
{
    
    dispatch_queue_t downloadQueue = dispatch_queue_create("Get Member Infos", NULL);
    
    
    
    dispatch_async(downloadQueue, ^{
    
        NSData *result = [self searchMemberInfo];
    
        id strResult=nil;
    
        int cpt;
    
        NSError* error;
    
        strResult = [NSJSONSerialization JSONObjectWithData:result options:0 error:&error];
    
        
    
        _liste = [[NSMutableArray alloc]init];
    
        
    
        for(cpt=0; cpt<[strResult count];cpt++)
    
        {
    
            NSDictionary *dicoTemp = [strResult objectAtIndex:cpt];
    
            NSMutableArray* arrayTemp = [[NSMutableArray alloc]init];
    
            
    
            [arrayTemp addObject:[dicoTemp objectForKey:@myCivilitu]];                  //0
    
            [arrayTemp addObject:[dicoTemp objectForKey:@mySurname]];                       //1
    
            [arrayTemp addObject:[dicoTemp objectForKey:@myFirstName]];                    //2
    
            [arrayTemp addObject:[dicoTemp objectForKey:@myAdress]];                   //3
    
            [arrayTemp addObject:[dicoTemp objectForKey:@myZip]];                  //4
    
            [arrayTemp addObject:[dicoTemp objectForKey:@myCity]];                     //5
    
            [arrayTemp addObject:[dicoTemp objectForKey:@myTelephone]];                       //6
    
            [arrayTemp addObject:[dicoTemp objectForKey:@myEmail]];                     //7
    
[_liste addObject:arrayTemp];
    
        }
    
        
    
        if(_liste.count!=0)
    
        {
    
        [actview stopAnimating];
    
        [loadingView removeFromSuperview];
    
            
    
        _civilite.text=[[_liste objectAtIndex:0]objectAtIndex:0];
    
        _nom.text=[[_liste objectAtIndex:0]objectAtIndex:1];
    
        _prenom.text=[[_liste objectAtIndex:0]objectAtIndex:2];
    
        _region.text=@"";
    
        _dep.text=@"";
    
        _adresse.text=[[_liste objectAtIndex:0]objectAtIndex:3];
    
        _cp.text=[[_liste objectAtIndex:0]objectAtIndex:4];
    
        _ville.text=[[_liste objectAtIndex:0]objectAtIndex:5];
    
        _tel.text=[[_liste objectAtIndex:0]objectAtIndex:6];
    
        _mail.text=email;
    
        }
    

    
    });
    
}
    
- (NSData *)searchMemberInfo {
    
    
    
    NSURL *url = [NSURL URLWithString:[NSString stringWithFormat:@%@", @http://www.mywebsite.org/getInfos.php]];
    
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
    
    
    
    NSString *requestFields = @"";
    
    requestFields = [requestFields stringByAppendingFormat:@pwd=%@&;", password];
    
    requestFields = [requestFields stringByAppendingFormat:@admail=%@", email];
    
    
    
    requestFields = [requestFields stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    
    NSData *requestData = [requestFields dataUsingEncoding:NSUTF8StringEncoding];
    
    request.HTTPBody = requestData;
    
    request.HTTPMethod = @POST;
    
    
    
    NSHTTPURLResponse *response = nil;
    
    NSError *error = nil;
    
    NSData *responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];
    
    if (error == nil && response.statusCode == 200) {
    
    }
    
    else {
    
    }
    
    
    
    return responseData;
    
}

    _liste me retournait ça lors d'un NSLog:

     



    2014-05-20 10:31:59.422 MyApp[4294:4b13] liste: (
            (
            Mme,
            Renault,
            "M\U00e9gane",
            "Place de Clichy",
            75013,
            "Paris, France",
            0836656565,
            "toto@toto.com",
        )
    )




    Maintenant le traitement asynchrone:

     



    
- (void)searchMemberInfo {
    
    
    
    NSURL *url = [NSURL URLWithString:[NSString stringWithFormat:@%@", @http://www.monsite.org/getInfos.php]];
    
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
    
    
    
    NSString *requestFields = @"";
    
    requestFields = [requestFields stringByAppendingFormat:@pwd=%@&;", password];
    
    requestFields = [requestFields stringByAppendingFormat:@admail=%@", email];
    
    
    
    requestFields = [requestFields stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    
    NSData *requestData = [requestFields dataUsingEncoding:NSUTF8StringEncoding];
    
    request.HTTPBody = requestData;
    
    request.HTTPMethod = @POST;
    
    
    
    NSHTTPURLResponse *response = nil;
    
    NSError *error = nil;
    
    [NSURLConnection sendAsynchronousRequest:request queue:[[NSOperationQueue alloc]init] completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {
    
        if ([data length] >0 && error == nil)
    
        {
    
            
    
            // DO YOUR WORK HERE
    
            
    
            id strResult=nil;
    
            int cpt;
    
            NSError* erreur;
    
            strResult = [NSJSONSerialization JSONObjectWithData:data options:0 error:&erreur];
    
            
    
            _liste = [[NSMutableArray alloc]init];
    
            
    
            for(cpt=0; cpt<[strResult count];cpt++)
    
            {
    
                NSDictionary *dicoTemp = [strResult objectAtIndex:cpt];
    
                NSMutableArray* arrayTemp = [[NSMutableArray alloc]init];
    
                
    
                [arrayTemp addObject:[dicoTemp objectForKey:@laCivilite]];                  //0
    
                [arrayTemp addObject:[dicoTemp objectForKey:@leNom]];                       //1
    
                [arrayTemp addObject:[dicoTemp objectForKey:@lePrenom]];                    //2
    
                [arrayTemp addObject:[dicoTemp objectForKey:@lAdresse]];                   //3
    
                [arrayTemp addObject:[dicoTemp objectForKey:@leCodePostal]];                  //4
    
                [arrayTemp addObject:[dicoTemp objectForKey:@laVille]];                     //5
    
                [arrayTemp addObject:[dicoTemp objectForKey:@leTelephone]];                       //6
    
                [arrayTemp addObject:[dicoTemp objectForKey:@lEmail]];                     //7
    
                [arrayTemp addObject:[dicoTemp objectForKey:@type]];                      //8
    
            }
    
            
    
            if(_liste.count!=0)
    
            {
    
                //NSLog(@liste: %@", _liste);
    
                
    
                [actview stopAnimating];
    
                [loadingView removeFromSuperview];
    
                
    
                _civilite.text=[[_liste objectAtIndex:0]objectAtIndex:0];
    
                _nom.text=[[_liste objectAtIndex:0]objectAtIndex:1];
    
                _prenom.text=[[_liste objectAtIndex:0]objectAtIndex:2];
    
                _adresse.text=[[_liste objectAtIndex:0]objectAtIndex:3];
    
                _cp.text=[[_liste objectAtIndex:0]objectAtIndex:4];
    
                _ville.text=[[_liste objectAtIndex:0]objectAtIndex:5];
    
                _tel.text=[[_liste objectAtIndex:0]objectAtIndex:6];
    
                _mail.text=email;
    
            }
    

    
            
    
        }
    
        else if ([data length] == 0 && error == nil)
    
        {
    
            NSLog(@Nothing was downloaded.);
    
        }
    
        else if (error != nil){
    
            NSLog(@Error = %@", error);
    
        }
    
    }];
    
}

  • Ben77650Ben77650 Membre
    mai 2014 modifié #33

    PS : Pas top la façon dont tu construits tes requestFields, au passage :


    1) Allouer des NSString à  chaque fois en demandant une nouvelle NSString avec "stringByAppendingFormat:" est un peu du gâchis, tu alloues une nouvelle chaà®ne à  chaque fois c'est un peu du gâchis. Si tu comptes construire une chaà®ne bout par bout, utilise plutôt NSMutableString, et travaille directement sur cette NSMutableString plutôt que recréer des nouvelles instances à  chaque fois.


    2) Tu appliques "stringByAddingPercentEscapesUsingEncoding:" sur toute ta chaà®ne, alors qu'il ne faut pas remplacer tes "=" et "&" de toute ta chaà®ne, il ne faut échapper que les valeurs. Ainsi si tu veux passer 2 paramètres a et b donc les valeurs sont "val&a" et "je dis b=1", il faut échapper le "&" de "val&a" et le "=" de "je dis b=1" mais pas le "&" ni le "=" de "a=val%26a&b=je%20dis%20b%3D1".

    En bref, dans ton cas il ne faut échapper que les variables nom_table, limite et rang, pas toute la chaà®ne


    3) [NSString stringWithFormat:@%@", str] est inutile et du gâchis (je suis étonné que tu n'aies pas un warning, d'ailleurs). Pas la peine de passer par un format pour mettre une chaà®ne qui est directement un litéral. Autant directement utiliser la chaà®ne litérale str et enlever complètement ton stringWithFormat qui ne sert strictement à  rien.



     

    C'est mieux selon toi comme ça donc ?



    
NSURL *url = [NSURL URLWithString:@http://www.monsite.org/getInfos.php];
    
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
    
    
    
    
    
    NSString *requestFields = [NSString stringWithFormat:@pwd=%@&;admail=%@",password,email];
    
requestFields = [requestFields stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    
NSData *requestData = [requestFields dataUsingEncoding:NSUTF8StringEncoding];
    
request.HTTPBody = requestData;
    
request.HTTPMethod = @POST;

  • FKDEVFKDEV Membre
    mai 2014 modifié #34

    On ne sait toujours pas d'où vient le problème initial de performance.

    Je pense que la suggestion de Larme d'utiliser Instrument était la meilleure.

    Quand on a un client et des délais, on ne part pas dans de la réécriture de code pour la beauté du geste sans avoir fait des mesures.

    Le fait que "ça vient de sendsynchronousrequest" reste une hypothèse. La bonne démarche pour un étudiant qui veut devenir autonome, c'est de vérifier cette hypothèse avec Instruments. 


     


    La suggestion du prof de mettre un sendsynchronousrequest dans un bloc à  part ne me parait pas si stupide dans le principe, pédagogiquement parlant.

    D'autant que le sendAsynchronous qui utilise le completionBlock utiliserait sendsynchronous en interne .


    En ce qui concerne git, mon avis est qu'il faut passer quelques heures à  lire des tutos et ensuite utiliser SourceTree. Malheureusement, on n'a pas plus simple pour l'instant (ou peut-être le système intégré à  Xcode mais je ne l'ai jamais utilisé).

    Ca fait partie des domaines du développement où on fait un pas en avant dans le principe et deux pas en arrière dans le concret.

     


  • Ben77650Ben77650 Membre
    mai 2014 modifié #35


    On ne sait toujours pas d'où vient le problème initial de performance.

    Je pense que la suggestion de Larme d'utiliser Instrument était la meilleure.

    Quand on a un client et des délais, on ne part pas dans de la réécriture de code pour la beauté du geste sans avoir fait des mesures.

    Le fait que "ça vient de sendsynchronousrequest" reste une hypothèse. La bonne démarche pour un étudiant qui veut devenir autonome, c'est de vérifier cette hypothèse avec Instruments. 




     


    Je présume qu'une fois que je suis sur Instruments (qui se lance via Product > Profile, pour ceux qui comme moi chercherait ^^), je doit utiliser le Time Profiler ?


     


    Edit : Désolé Instruments c'est nouveau pour moi et je me perds un peu dessus


     


    Edit 2: Ce qui est étonnant c'est que quand j'utilise Time Profiler, même après 2 min d'utilisation totale, j'ai toujours pas mes infos qui s'affichent sur le Simulateur :/


     


    Edit 3: Même après plus de 6 min toujours rien


     


    Edit 4: Bon visiblement le souci est le même avec "Allocations" ou Leaks. Cependant pas de souci si j'utilise l'Activity Monitor


  • AliGatorAliGator Membre, Modérateur
    #36

    D'autant que le sendAsynchronous qui utilise le completionBlock utiliserait sendsynchronous en interne .

    Du tout, pour moi c'est l'inverse.

    Car l'implémentation interne de l'URL Loading System (je commence à  le connaà®tre pour avoir pas mal travaillé dessus dans le cadre de OHHTTPStubs) est que la requête est gérée par la NSRunLoop (qui en gros sur le principe fait un select sur le socket à  chaque itération de RunLoop, pour voir s'il y a des nouvelles données et les traiter en conséquence), et est donc asynchrone par nature, vu comment c'est implémenté sous le capot.

    C'est d'ailleurs pour ça qu'à  l'origine / historiquement, pour utiliser NSURLConnection on n'avait ni sendSynchronousRequest ni sendAsynchronousRequest, mais on devait tout faire avec les delegate, le "connection:didReceiveData:" etc. Tout était déjà  événementiel.

    Donc NSURLConnection est asynchrone par nature, et sendSynchronousRequest appelle ce mécanisme asynchrone et bloque le thread courant (sans doute en faisant tourner la RunLoop avec un "while([NSRunLoop runUntilDate:modes:] && xxx)" un truc comme ça, donc une attente active " ou sinon au mieux un semaphore quoique j'en doute car ça bloquerait la RunLoop principale) pour rendre tout ce mécanisme pseudo-synchrone.
    Et pas l'inverse.
  • FKDEVFKDEV Membre
    #37


    Je présume qu'une fois que je suis sur Instruments (qui se lance via Product > Profile, pour ceux qui comme moi chercherait ^^), je doit utiliser le Time Profiler ?


     




     


    Product | Profiler puis Time Profiler, oui c'est ça.


    A un moment donné, Instruments te demande ton mot de passe Administrateur. Peut-être que c'est là  que ça coince.

  • Ben77650Ben77650 Membre
    #38

    Non, j'ai bien rentré mon mot de passe.


     


    L'écran d'accueil marche bien, l'écran de connexion aussi, à  ce moment la quand je rentre mes ID de connexion il doit me sortir les infos du compte, hors c'est la que ça bloque et que ça m'affiche rien, si ce n'est mon spinner qui tourne et me dit de patienter (cf code 1 dans le message d'Aujourd'hui de 9H37)


  • FKDEVFKDEV Membre
    #39

    Ben déjà  que te renvoie ton serveur ? Mets un point d'arrêt au retour de ton send request et vérifie que tu n'as pas eu une erreur.


    Tu as vu la remarque d'Ali sur le fait que tu envoies tes données dans le body de ta requête HTTP et non pas dans l'URL ?


     


    Une remarque : tu dois éviter de manipuler tout ce qui concerne les vues dans une queue de background.


    La règle c'est de faire tout ce qui est GUI dans la main queue.


     


    Par exemple :



    
dispatch_async(dispatch_get_main_queue(), ^{
    
[actview stopAnimating];
    
    [loadingView removeFromSuperview];
    
}); 

    Mais le mieux c'est de faire comme indiqué par Ali, c'est -à -dire passer dispatch_get_main_queue() à  la méthode sendAsynchronousRequest pour que le completionBlock.

  • AliGatorAliGator Membre, Modérateur
    #40
    FKDEV attention quitte à  retranscrire mes remarques à  pas faire téléphone arabe ^^

    1) J'ai fait la remarque que les données était dans le body car Ben demandait si c'était normal de ne pas voir "pwd=xxx&admail=yyy" dans son URL. Forcément, il les met dans le body donc c'est logique qu'il ne les voit pas dans l'URL. Mais c'est peut-être ce qu'attend son serveur, on ne sait pas (il n'y a que lui qui connaisse le serveur et son API)

    2) "sendAsynchronousRequest:queue:completionHandler:" prend comme paramètre pour "queue:" une NSOperationQueue, et non une dispatch_queue_t. Donc il faut lui passer [NSOperationQueue mainQueue], pas dispatch_get_main_queue().
  • Ben77650Ben77650 Membre
    #41

    Ok un breakpoint à  été mis au niveau du "return responseData". Mais je doit regarder quel log à  quel moment s'il vous plait ? (Désolé je débute en débug)


     


    @Ali: Oui je crois que c'est ce qu'attends mon serveur, enfin comment je peut en être sur ? J'ai un POST dans mon webservice si c'est ça la question


  • samirsamir Membre
    #42


    FKDEV attention quitte à  retranscrire mes remarques à  pas faire téléphone arabe ^^




    on apprend pleines de choses dans ce forum :)


     


    http://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9phone_arabe

  • Ben77650Ben77650 Membre
    #43

    Si tu pouvais éviter de flooder ça serait cool (surtout que je suis notifié à  chaque réponse)


  • muqaddarmuqaddar Administrateur
    #44


    Si tu pouvais éviter de flooder ça serait cool (surtout que je suis notifié à  chaque réponse)




     


    C'est pas méchant non plus hein, t'as pas eu 10 posts de flood depuis le début et ton sujet fait déjà  3 pages... un flood pour se détendre de temps en temps, ça fait pas de mal sur un forum de programmation.

  • NasatyaNasatya Membre
    #45

    Enlève tes notifications... 


     


    Sinon pour ton souci je te conseil pour pouvoir debug au moins les différences de réponses entre le sendSynchronousRequest et le sendAsynchronousRequest l'utilisation de "Charles" (payant mais avec une version d'essais utilisable) il me semble qu'il te donne l'url et les paramètres envoyés dans ta requête et les réponses associé au moins tu sauras si elles sont pareilles. Ensuite il doit bien exister des logiciels qui permettent d'envoyer des requêtes avec des méthode post (je n'ai pas de logiciel en tête) ce qui te permettrais de voir ce que répond le serveur en modifiant éventuellement les paramètres ça serait bien plus rapide que de le faire dans ton application.


     


    Sinon tu décodes ton retour en string via la méthode stringWithData... avant de le log comme ça tu verras que ta réponses est un tableau vide ce qui veut dire que ta requête est bien envoyé, bien reçus, et que ton application reçoit bien une réponse vide ce qui voudra dire que comme te le dit Ali depuis pas mal de temps que le souci ne vient probablement pas de la méthode mais bien de ta construction de requête.


     


    Bon courage pour la suite.


  • Ben77650Ben77650 Membre
    #46

    Non justement j'ai mes notifications pour savoir quand j'ai une réponse c'est utile.


     


    Sinon j'ai pas tout compris à  ce que tu m'as dit, juste la requête marche en synchrone mais pas en asynchrone, or je ne la change pas donc je pense vraiment pas que l'erreur vienne de la


  • NasatyaNasatya Membre
    #47

    Ok ben test avec le logiciel "Charles" qui te permet de sniffer le réseaux et qui te donnera plus d'info sur ce qui se passe entre ton device et ton serveur.


  • NasatyaNasatya Membre
    #48

    J'avais pas fait attention mais c'est le mot de passe et le mail de l'utilisateur que tu passes en POST dans une requête en http? As tu au moins chiffré le mot de passe? C'est juste que ça me parait pas top au niveau sécurité en même temps il y a peut être d'autre mécanisme que je ne voit pas.


  • Ben77650Ben77650 Membre
    #49

    Comme énoncé dans un autre sujet le MDP est passé en MD5 que ça soit sur l'appli iPhone ou l'appli Android (voire même peut être le site web)


  • NasatyaNasatya Membre
    #50

    Ok ça marche au temps pour moi... Le MD5 c'est mieux que rien mais moins bien que le reste;).


  • Ben77650Ben77650 Membre
    #51

    Oui j'en ai pris conscience après une petite discussion avec AliGator


     


     




     


    • Enfin, en quoi c'est sécurisé, puisque si tu stockes le MD5 du mdp, c'est que c'est ce MD5 que tu envoies au serveur dans ta requête. Donc si tu utilises cette technique, qqun qui voudrait usurper ton identité et se connecter avec ton compte n'a pas besoin de ton mot de passe, il a juste besoin du MD5 de ton mot de passe qu'il va faire transiter dans la requête et basta.
    • Et au pire il existe plein de sites web qui te permettent de trouver une chaà®ne qui a un MD5 donné (d'ailleurs on s'en fout que ce soit le vrai mot de passe, du moment que la chaà®ne ait le même MD5 au final)

     

    En tout cas, en résumé, le MD5 est loiiiinn d'être une protection quelconque, et stocker le mot de passe en MD5 dans NSUserDefaults c'est comme fermer à  clé ton cadenas mais y scotcher la clé dessus  ;)

     



  • muqaddarmuqaddar Administrateur
    mai 2014 modifié #52

    Comment protéger le mot de passe sur le réseau à  part avec https (SSL) ?


  • NasatyaNasatya Membre
    #53

    C'est un très vague sujet avec des réponses plus ou moins satisfaisante... Le souci pour moi ici est plutôt le MD5 qui peut être (souvent) "traduit" ce qui veut dire que non seulement la personne aura accès au compte de l'utilisateur mais aussi si il tombe sur une personne pas très prudente peut être a son compte mail, facebook, twitter... Alors je ne dis pas que j'ai LA solution ultime je ne dis même pas quelle existe mais la ça me parait quand même un peu léger.


  • Ben77650Ben77650 Membre
    mai 2014 modifié #54

    Si vous avez une meilleure solution, j'en parlerais à  mon boss ;)


     


    Edit: bon a priori c'es temporaire selon mon boss


  • jojolebgjojolebg Membre
    mai 2014 modifié #55

    Edit: bon a priori c'es temporaire selon mon boss


     


    Il dise tous ça, quand on leur parle de sécurité, ou de qualité logicielle.


  • AliGatorAliGator Membre, Modérateur
    #56
    Et c'est comme ça qu'on a des failles de sécurité partout.

    Ceux qui croit encore qu'envoyer un mot de passe en MD5 permet d'être + sécurisé que de l'envoyer en clair ont sans doute à  prendre des cours du soir. Sauf qu'en attendant ils ont malheureusement de beaux jours devant eux, pensant que la sécurité c'est pas si grave et si important...

    Alors qu'il est si simple de faire du SSL (tellement standard que ça n'ajoute rien à  ton code et est géré par le système) et ensuite de pouvoir faire transiter son mdp en Basic Auth sans avoir de crainte qu'il soit visible vu que l'échange SSL est chiffré...
  • Ben77650Ben77650 Membre
    #57

    Selon les discussions de mon boss et de mon collègue SSL est pas plus sécurisé.


     


    Je te renvoie vers l'affaire HeartBleed si tu n'es pas convaincu


  • AliGatorAliGator Membre, Modérateur
    #58

    Selon les discussions de mon boss et de mon collègue SSL est pas plus sécurisé.
     
    Je te renvoie vers l'affaire HeartBleed si tu n'es pas convaincu

    Looool faut peut-être un peu vérifier ses arguments quand même avant de sortir des trucs comme ça.
    • HeartBleed était une faille de l'implémentation d'OpenSSL. Ca peut arriver, tout comme il arrive qu'il y ait des failles dans un OS (OSX, Windows, etc). C'est une erreur de codage de la personne qui a implémenté le protocole. Ceux qui utilisaient d'autres librairies que OpenSSL pour implémenter la couche SSL de leur serveur n'étaient pas du tout impacté.
    • Mais le protocole SSL (son principe de fonctionnement, et tout le workflow qui est prévu par la couche de transport SSL, les principes de mécanismes de handshake pour échanger les secret keys et tout) lui est étudié pour être sécurisé. Le principe de SSL fait que les communications sont chiffrées entre le client est le serveur
    • Alors qu'utiliser MD5 c'est dans le principe même que c'est foireux et que ça ne protège de rien du tout
    Pour faire une analogie :
    • Utiliser MD5, c'est comme mettre un cadenas à  ton coffre mais scotcher la clé dessus ou mettre un post-it à  côté pour dire "le code c'est ça". Ou alors envoyer un message, mais en pliant ta feuille de papier en 4 en se disant "comme ça les gens vont pas pouvoir lire ce qui est écrit dessus", sauf qu'il leur suffit de déplier la feuille pour lire. Bref, c'est sur le principe même c'est pas sécurisé.
    • Utiliser SSL, c'est comme mettre un cadenas et garder la clé. Sur le principe c'est vachement plus sécurisé si tu ne laisse pas trainer la clé de ton cadenas.
    • Ce qui s'est passé avec HeartBleed, c'est un peu comme si on avait découvert qu'une série (version) entière de la production des cadenas de la marque X (OpenSSL) avaient un défaut de fabrication et qu'on pouvait les ouvrir sans trop trop de difficulté avec une épingle à  cheveux et un peu de dextérité. Par contre, toutes les autres "séries" (versions) produites par cette même "marque" (la lib OpenSSL) n'ont pas ce vice de fabrication, et les cadenas des autres "marques" (des autres libs SSL du marché, comme gnuTLS, polarSSL, matrixSSL, ...) n'ont pas ce problème. Dans tous les cas, ça n'enlève en rien le fait que mettre un cadenas sur ton coffre est plus sécurisé que juste plier ta feuille en 4, même si ça peut arriver que certains cadenas soient d'une mauvaise série / crochetables suite à  un défaut de fabrication (bug introduit par un développeur de la lib OpenSSL dans la version 0.9.8 et corrigé dans la 1.0.1g)
    Bref, ne mélangeons pas les torchons et les serviettes, c'est pas parce qu'il y a eu un bug dans une implémentation possible d'une librairie gérant SSL dans une version donné que tout le concept même de SSL et tous les mécanismes qu'il met en place pour sécuriser et chiffrer les échanges ne sert à  rien et qu'on a aussi bien fait de juste plier sa feuille en 4 pour ne pas que des yeux curieux puissent le lire.


    Si avec tout ça toi et ton boss sont toujours convaincus que "SSL c'est pas plus sécurisé que MD5", c'est qu'il serait peut-être temps de prendre des cours sur la sécurité avant de dire ce genre de choses ;)
  • FKDEVFKDEV Membre
    mai 2014 modifié #59


    FKDEV attention quitte à  retranscrire mes remarques à  pas faire téléphone arabe ^^1) J'ai fait la remarque que les données était dans le body car Ben demandait si c'était normal de ne pas voir "pwd=xxx&admail=yyy" dans son URL. Forcément, il les met dans le body donc c'est logique qu'il ne les voit pas dans l'URL. Mais c'est peut-être ce qu'attend son serveur, on ne sait pas (il n'y a que lui qui connaisse le serveur et son API)2) "sendAsynchronousRequest:queue:completionHandler:" prend comme paramètre pour "queue:" une NSOperationQueue, et non une dispatch_queue_t. Donc il faut lui passer [NSOperationQueue mainQueue], pas dispatch_get_main_queue().


    1) . En fait je voulais m'appuyer sur ta remarque car je voulais ajouter que s'il met les donnees dans le body avec un percent escape alors il doit normalement le préciser dans le content-type :

    [request setValue:@application/x-www-form-urlencoded forHTTPHeaderField:@Content-Type];

    Mais j'ai oublié.

    Et dans les dernier extraits de code, le percent escaping n'est toujours pas fait au bon endroit (comme l'a dit Ali, bien que mes propos n'engage pas sa responsabilité :). Donc meme si le serveur attend bien un POST (genre un POST, c'est plus sécurisé pour mettre un mdp en clair...), ça ne peut pas marcher.



    2) désolé de te coller des erreurs sur le dos.
  • Ben77650Ben77650 Membre
    #60

    Ali perso je suis une bille en sécurité informatique, mais mon boss est mon collègue ont l'air plus calés. En aucun cas ils ont dit que MD5 c'est mieux que SSL, ils ont juste dit que rien n'était infaillible, pas même SSL et m''ont parlé de HeartBleed (que je ne connaissais pas).


     


    Maintenant je leur transmettrais ton message, et si mon boss souhaite toujours utiliser MD5, je me plierais à  ses exigences, mais j'aurais fait mon devoir en le prévenant ;)


  • AliGatorAliGator Membre, Modérateur
    #61
    Evidemment que rien n'est infaillible, mais plutôt que de laisser la porte de ta maison grande ouverte, ou même juste fermée mais pas à  clé, c'est quand même mieux de fermer la porte à  clé et mettre une alarme et un système de sécurité, ça n'empêchera pas un voleur professionnel qui sait trouver la faille d'aller te cambrioler, mais c'est quand même mieux que de laisser la porte grande ouverte.

    J'ai jamais dit que SSL était infaillible. J'ai juste dit que SSL était un algo de chiffrement et un protocole standard et éprouvé (et approuvé par plein d'experts en sécurité dont c'est le métier et qui ont pensé à  tout plein de cas bien complexes et tout) pour faire des échanges sécurisés et chiffrés entre un client et un serveur... alors que MD5 n'était qu'un hash et ne chiffrait rien du tout.


    Le problème dans ce débat, c'est que dans tous les cas ce sont 2 choses qui n'ont rien à  voir.

    Le MD5 est un hash. Ca n'a rien d'un chiffrement de données.

    Un hash est ce qu'on appelle en mathématique une fonction (ou application) surjective. Plusieurs chaà®nes peuvent avoir le même hash (le même MD5) et un MD5 n'a donc pas qu'une seule chaà®ne source (donc on n'a pas de fonction qui pour un MD5 donné donne à  coup sûr la chaà®ne qui a été utilisée à  l'origine, un hash n'est pas une fonction réversible)

    Alors qu'un algo de chiffrement est forcément bijectif et inversible par définition, puisque le but c'est de pouvoir à  un certain point retrouver le message d'origine qui avait été envoyé par l'expéditeur

    Donc comparer une fonction de hachage et un algo de chiffrement ça n'a pas trop de sens. Si tu veux faire du chiffrement il faut utiliser un algo de chiffrement (SSL ou d'autres, après tout ce n'est pas le seul, c'est juste le plus connu, le plus répandu, et le plus éprouvé). Si tu veux faire du hachage là  tu pourrais utiliser une fonction de hashage.

    Si tu veux faire un gratin de pommes de terres, tu n'utilises pas des carottes. C'est très bon les carottes, c'est pas le problème, c'est juste pas fait pour ça.
Connectez-vous ou Inscrivez-vous pour répondre.