Publicidade

Gabriel Heming

Moderadores
  • Total de itens

    3.204
  • Registro em

  • Última visita

  • Dias vencidos

    65

Gabriel Heming venceu o dia em Maio 19

Teve o conteúdo mais curtido

Reputação

604 Incrível

Sobre Gabriel Heming

  • Classificação
    Especialista em Desenvolvimento de Software
  • Data de Nascimento 05-05-1989

Informações Pessoais

  • Sexo
    Masculino
  • Interesses
    PHP, C#/.NET, Microsoft Dynamics AX, JavaScript, Java, OOP, Padrões de Arquiteturas e de Projeto, Engenharia de Software.

Últimos Visitantes

43.652 visualizações
  1. Particularmente, sei desenvolver para desktop em Java, C# e PHP (apenas com o PHP Desktop). Se for para escolher uma delas pra aplicação desktop, eu fico com C# (seja em WPF ou Windows Forms). Gostaria de poder opinar sobre Python, mas não posso, sei apenas o básico dela.
  2. Acredito que você estará melhor assistido na área de javascript. Movido: PHP -> JavaScript
  3. c#

    Eu separei sua questão em um novo tópico, evite reutilizar tópicos existentes.
  4. Essa é uma prática negativa do ponto de vista de SEO.
  5. c#

    Movido: C/C++ -> .NET
  6. Nos casos de períodos, existe a classe DatePeriod O código abaixo vai lhe exibir a data atual e mais 14 recorrências: foreach(new DatePeriod(new DateTime() , new DateInterval('P1D') , 14) as $date) { echo $date->format('Y-m-d').'<br />'; }
  7. Anteriormente, acabei escrevendo na pressa e esqueci de pontuar, mas a quetão de bloquear o acesso após três tentivas é muito importante e realmente protege. Nesse caso, "bola dentro". Na programação, 99.9% do desenvolvimento pode ser orientado com a expressão "menos é mais". Exceto a segurança. Ela se baseia em outra regra, que eu denomino "balanço". O balanço seria entre segurança X velocidade (ou, UX, User eXperience). Se o seu sistema for o estado da arte em segurança, ele será lento. Se for rápido demais, vai ser frágil. Tanto é que, as funções hash_equals e password_verify são lentas, para justamente evitar a força bruta. Além de serem lentas, elas possuem alguma proteção contra timing attack. Ela era como eu imaginava. Você pode substituir pela PDO ou MySQLi que terá um proteção superior.
  8. Leituras complementares http://php.net/manual/en/security.php http://stackoverflow.com/users/2224584/scott-arciszewski https://paragonie.com/blog https://phpdelusions.net/
  9. Seu código impõe uma certa segurança, mas acaba pecando em alguns aspectos. Não entenda que seu código possui ou não segurança. Ele possui uma segurança básica, mas, quando a exigência é sair do básico, está fragilizado. Olhando em ordem pelo que vi no seu código: Sessões Uma leitura bem importante é sobre a segurança de sessões : Sessions and Security SQL Injection Praticamente não precisaia verificar a sua classe Sanitize para verificar que ela é vulnerável. Existe muito além de sanitizar para evitar SQL Injection. Mesmo sanitizando completamente, no momento que você interpola uma consulta SQL como uma string, seu código se torna vulnerável. Referências: https://phpdelusions.net/sql_injection Inputs o código abaixo é desnecessário $login_hash = sha1('user_login'); $password_hash = sha1('user_password'); Quem tiver acesso ao HTML verá que o name do input de login e senha são "diferentes", ou seja, são hashs. Tanto que são disponíveis ao usuário. Só acaba gerando mais processamento. Senha e hash Sha1 sim é inseguro. $user_pass = sha1($_POST[$password_hash]); Tudo que foi dito no tópico abaixo sobre o md5 se aplica ao sha1: Foi linkado no artigo acima, mas vale a pena linká-lo novamente. It's All About Time é um dos melhores artigos explicativos sobre como são realizadas as quebras de senha através de ataques de tempo (timing attack). Considerações finais "Tudo depende do contexto" (essa frase é minha mesmo). Você não precisa fazer tudo que é tipo de segurança, vai depender muito do foco do seu sistema. Por exemplo, um CMS não requer segurança extrema. Por outro lado, um sistema financeiro requer até que dados persistidos em SGBD sejam criptografados. PS.: Desde a thread do artigo acima, estou juntando material para fazer uma série de vídeos sobre segurança. Vejo que existe muito material em inglês, mas muito pouco em português. Acho que esse final de semana eu lanço uma parte e abro discussão sobre como melhorar a segurança de aplicativos e, talvez, mitigar algumas boas discussões sobre o que é ou não necessário.
  10. Seu código que está com a complexidade ciclomática muito alta. Use early returns para reduzí-la. Quanto a validação, tudo que não permitir a persistência no SGBD é uma exceção, ou seja: if($this->usuario) { throw new RuntimeException('Campo Usuário já está cadastrado em nosso banco de dados.'); } if($this->nomesobrenome) { throw new RuntimeException('Campo Nome/Sobrenome já está cadastrado em nosso banco de dados.'); } /** demais validações **/
  11. Plug-in XML Tools do Notepad++ Atente-se que sua questão não é de PHP. Movido: PHP -> Software e Apps
  12. Princípio orientado à objeto denominado Tell, don't ask. BasicamenteVocê deve mandar/dizer para que uma classe/objeto faça algo e não perguntar a ela sobre o que, ou se, ela realizou. Exceto se o nome do método é uma pergunta (get, is, has, can, etc..). Em um método denominado insert espera-se que o método insira um registro. Se tudo ocorrer certo, um registro será inserido. Se um registro não foi inserido, algo que não estava esperado ocorreu. Se inesperado ocorreu, é uma exceção.
  13. Por isso eu comentei do uso de um service provider. Um service provider (provedor de serviços) é basicamente um gerenciador de serviços. Ele fica responsável por instânciar e disponibilizar objetos (serviços) para a sua aplicação. Só requer um pouco de estudo em cima para entender como e quando deve ser utilizado.
  14. Vamos lá, tem muito o que ser corrigido. Não leve para o lado pessoal, são críticas construtivas. Herança x Associação - Herança: é um. Ex.: um carro é um veículo; - Associação: usa um. Ex.: um carro usa gasolina. A classe Cadastro é um aluno ou usa um aluno? Logo, o uso de herança é incorreto entre Aluno e Cadastro. PDO e Banco No código a seguir: $stmt = $pdo->prepare($insert); a variável $pdo é uma instância de Banco: $pdo = new Banco(); E a classe Banco não implementa o método prepare. Sugiro utilizar diretamente PDO, já é uma classe bem completa, apesar de ainda pode ser melhorada. $pdo = new PDO(/** configurações de conexão **/); O que você poderia utilizar é algum tipo de service provider. Pode ver um pouco mais aqui: https://laracasts.com/discuss/channels/lumen/why-use-service-providers-any-examples?page=1
  15. É, sua resposta está aqui: Para usar o apache 2.4, tem que atualizar para o CentOS 7.