Autor Tópico: Bugs que não devem ser transferido para versão 6  (Lida 8079 vezes)

saulobborges

  • Expert
  • *****
  • Mensagens: 1392
    • SGi Sistemas
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #30 Online: Agosto 16, 2011, 11:38:45 pm »
Boa noite a todos, bem logo que o Régis postou os bugs eu comecei a fazer alguns teste e fiquei pasmado com tantos descuidos, o que mais me preocupou foi com certeza questão da segurança das informações visto que "diga-se de passagem", segurança sempre vem em primeiro lugar.

Bem no link http://www.gestorcustom.com.br/bug/seguranca1/ o Régis apontou um problema que creio que a grande maioria do pessoal não se atentou, mas é uma situação preocupante porque o tipo de sistema que desenvolvemos não raro irá rodar em plataforma própria (nossa) e iremos disponibilizar o mesmo como serviço (Saas), e isso acontece por inúmeros problemas relacionados a roubos de códigos fonte e até de sistema inteiros. Creio que a grande maioria já percebeu que a melhor maneira de nos protegermos é mantendo uma estrutura própria para os nossos clientes.
Como o próprio Régis mostrou independente se você trabalha com Linux ou Windows como plataforma o problema apontado não é do scriptcase propriamente dito, e sim da maneira como o PHP lida com sessões, assim fiquei matutando em como resolver o problema.

Uma solução seria, oferecer no pacote um domínio ao cliente tipo www.cliente.com.br, o que não seria nada dispendioso ou caro, mas teríamos o problema dos nomes, não raro nosso cliente já tem um domínio e com certeza ele não vai querer um domínio www.xbqhyz2011.com.br pra acesso ao sistema pela própria dificuldade em lembra-lo e mesmo porque não tem nada haver com o nome da empresa dele.

Bem outra solução seria criar um subdomínio como domínio principal.... e isso aí!!!
eu mantenho atualmente um cloud e contratei Cpanel porque não tenho muito saco e nem muito conhecimento pra ficar mexendo em Linux, mas durante as minhas pesquisas constatei que se você no WHM criar uma nova conta usando um subdomínio o problema não acontece, ou seja, onde você deveria colocar o domínio completo (cliente.com.br) você coloca cliente.seudominio.com.br e cria uma conta raíz, ou seja um diretório será criado, por exemplo, /home/cliente/public_html/, só lembrando que para isso funcionar você não pode ter o mesmo subdomínio cliado em sua conta principal.

bem estou usando esta solução e me parece que deu certo, vou continuar os teste e informo caso tenha novidades.

Mais uma vez parabéns!!

Cleyton Euler

  • Expert
  • *****
  • Mensagens: 1149
    • Associação de Usuários Scriptcase
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #31 Online: Agosto 17, 2011, 10:09:45 am »
Uso uma solução também.

Na tabela de cliente uso um pseudocódigo de sessão para cada cliente.

Na aplicações eu valido esse código. Exemplo, quando o menu é carregado ele checa se o cliente que logou é o cliente daquele projeto.
Associação de Usuários Scriptcase
http://www.auscriptcase.com.br

Consultoria Scriptcase Versão 5
http://www.infinitusweb.com.br

Régis Matos

  • Global Moderator
  • Expert
  • *****
  • Mensagens: 632
  • Se a porta não se abrir, construa uma.
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #32 Online: Agosto 17, 2011, 06:44:18 pm »
Uso uma solução também.

Na tabela de cliente uso um pseudocódigo de sessão para cada cliente.

Na aplicações eu valido esse código. Exemplo, quando o menu é carregado ele checa se o cliente que logou é o cliente daquele projeto.


Clayton, cara... isso é muito bom... achei uma ideia tão boa que sugiro/ou que esse método deve ser nativo do modulo de segurança.... e claro não só no menu mais em todas as aplicações.... Seguindo os comentários que a nova versão 6 vai vim com o modulo de segurança novo, poderia ser add esse método que o Clayton disse. NATIVO NO MODULO DE SEGURANÇA.... 

Ótima solução Clayton...

O que vcs acham???



saulobborges

  • Expert
  • *****
  • Mensagens: 1392
    • SGi Sistemas
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #33 Online: Agosto 17, 2011, 07:14:28 pm »
Ótima idéia!

weber

  • Expert
  • *****
  • Mensagens: 516
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #34 Online: Agosto 22, 2011, 09:41:44 am »
Uso uma solução também.

Na tabela de cliente uso um pseudocódigo de sessão para cada cliente.

Na aplicações eu valido esse código. Exemplo, quando o menu é carregado ele checa se o cliente que logou é o cliente daquele projeto.


Clayton, cara... isso é muito bom... achei uma ideia tão boa que sugiro/ou que esse método deve ser nativo do modulo de segurança.... e claro não só no menu mais em todas as aplicações.... Seguindo os comentários que a nova versão 6 vai vim com o modulo de segurança novo, poderia ser add esse método que o Clayton disse. NATIVO NO MODULO DE SEGURANÇA.... 

Ótima solução Clayton...

O que vcs acham???

a ideia é muito boa, mudando de assunto mas nem tanto alguem sabe qual é sera a atualização que a netmake esta falando pro sc 6 sobre modulo de segurança ...

Régis Matos

  • Global Moderator
  • Expert
  • *****
  • Mensagens: 632
  • Se a porta não se abrir, construa uma.
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #35 Online: Agosto 29, 2011, 12:07:15 pm »
Sistemas PHP em minutos
Com ScriptCase é simples


Eu gosto muita da ferramenta... e concordo que agiliza muito... Show de Bola
Mais quem escreveu essa frase, aposto que nunca criou um formulário de impressão do tipo pdfreport...

Eita trem complicado!!!

Eu estou fazendo essa critica, no sentido para a nm rever esse conceito de relatório e termos um ganho de tempo realmente considerável... Principalmente esse tipo de aplicação que deveria ser simples de fazer em um sistema de desenvolvimento....

Na minha opinião... tem que melhorar ou ter o seguinte.

1º. Um método mais simples de posicionar os campos no formulário. (Método atual é uma vergonha)
2º. Uma forma de poder desenhar ou criar o formulário na própria ferramenta, eliminando a imagem de fundo!

3º. Será que na versão 6, tem alguma 9vidade nesse sentido?

-------
Link:
http://www.gestorcustom.com.br/bug/pdfreport1/


Haroldo

  • Expert
  • *****
  • Mensagens: 6264
  • Conhecimento diminui limitações.△TFA△
    • Infinitus Web Gestão Empresarial/Gestão ITIL/Consultoria Scriptcase
Re:Bugs que não devem ser transferido para versão 6
« Responder #36 Online: Agosto 29, 2011, 12:19:08 pm »
Bem, segue outra questão que não vejo como BUG mas que acho falha no SC, é a questão de multusuário.
Pegue uma tela qualquer, por exemplo cadastro de Clientes, abram em 2 estações, editem um cliente (o mesmo nas duas telas), exemplo o cliente XYZ.
Na primeira tela alterem o endereço, na segunda alterem um telefone, salve a primeira na tela depois salve na segunda tela.
O endereço digitado na primeira tela é perdido, se salvarem a segunda tela primeiro e depois a primeira o telefone alterado será perdido.
Isso porque o sc carrega todos os campos em memória e no salvamento descarrega todos os campos no update. Sei que o SC já guarda os campos alterados num array, porque não fazer o update só nesses campos?
Imaginem um sistema de reserva de passagem de Ônibus...
Vocês podem me perguntar, mas editar o mesmo cliente em dois lugares diferentes ao mesmo tempo é muito difícil de ocorrer,
Se esse cliente for uma empresa grande, com diversos departamentos, não é difícil não, pois já aconteceu comigo, e passei um carão pois a impressão que a empresa que usa meu sistema é que o mesmo estava perdendo informações e não era seguro.Demorei para detectar essa falha. Hoje as principais telas do meu sistema são com controle e não formulário, onde eu controlo os updates, os campos que serão salvos, etc... garantindo melhor o multiusuário.



« Última modificação: Agosto 29, 2011, 12:27:28 pm por [Infinitus Web 2.0] Haroldo »

Haroldo

  • Expert
  • *****
  • Mensagens: 6264
  • Conhecimento diminui limitações.△TFA△
    • Infinitus Web Gestão Empresarial/Gestão ITIL/Consultoria Scriptcase
Re:Bugs que não devem ser transferido para versão 6
« Responder #37 Online: Agosto 29, 2011, 12:41:21 pm »
Report Pdf, não uso imagem de fundo e desenho o layout todo na mão, e também não uso á área de interface dele, pois andei estudando o fonte gerado, e não me agradou em nada. Mas com o tempo passei a desenvolver rapidamente criando métodos que me apoiam no trabalho.


Sistemas PHP em minutos
Com ScriptCase é simples


Eu gosto muita da ferramenta... e concordo que agiliza muito... Show de Bola
Mais quem escreveu essa frase, aposto que nunca criou um formulário de impressão do tipo pdfreport...

Eita trem complicado!!!

Eu estou fazendo essa critica, no sentido para a nm rever esse conceito de relatório e termos um ganho de tempo realmente considerável... Principalmente esse tipo de aplicação que deveria ser simples de fazer em um sistema de desenvolvimento....

Na minha opinião... tem que melhorar ou ter o seguinte.

1º. Um método mais simples de posicionar os campos no formulário. (Método atual é uma vergonha)
2º. Uma forma de poder desenhar ou criar o formulário na própria ferramenta, eliminando a imagem de fundo!

3º. Será que na versão 6, tem alguma 9vidade nesse sentido?

-------
Link:
http://www.gestorcustom.com.br/bug/pdfreport1/



ricardo.resende

  • Novato
  • *
  • Mensagens: 27
Re:Bugs que não devem ser transferido para versão 6
« Responder #38 Online: Agosto 29, 2011, 03:23:50 pm »
Haroldo,

Se você ir em "Atribuir valores" e colocar NULL nos campos não resolve?

Bem, segue outra questão que não vejo como BUG mas que acho falha no SC, é a questão de multusuário.
Pegue uma tela qualquer, por exemplo cadastro de Clientes, abram em 2 estações, editem um cliente (o mesmo nas duas telas), exemplo o cliente XYZ.
Na primeira tela alterem o endereço, na segunda alterem um telefone, salve a primeira na tela depois salve na segunda tela.
O endereço digitado na primeira tela é perdido, se salvarem a segunda tela primeiro e depois a primeira o telefone alterado será perdido.
Isso porque o sc carrega todos os campos em memória e no salvamento descarrega todos os campos no update. Sei que o SC já guarda os campos alterados num array, porque não fazer o update só nesses campos?
Imaginem um sistema de reserva de passagem de Ônibus...
Vocês podem me perguntar, mas editar o mesmo cliente em dois lugares diferentes ao mesmo tempo é muito difícil de ocorrer,
Se esse cliente for uma empresa grande, com diversos departamentos, não é difícil não, pois já aconteceu comigo, e passei um carão pois a impressão que a empresa que usa meu sistema é que o mesmo estava perdendo informações e não era seguro.Demorei para detectar essa falha. Hoje as principais telas do meu sistema são com controle e não formulário, onde eu controlo os updates, os campos que serão salvos, etc... garantindo melhor o multiusuário.

Haroldo

  • Expert
  • *****
  • Mensagens: 6264
  • Conhecimento diminui limitações.△TFA△
    • Infinitus Web Gestão Empresarial/Gestão ITIL/Consultoria Scriptcase
Re:Bugs que não devem ser transferido para versão 6
« Responder #39 Online: Agosto 29, 2011, 04:02:20 pm »
Já fez esse teste?
Desde que me deparei com esse problema na versão 4 passei a tomar masi cuidado com relação a isso, recentemente não testei, mas se mexeram nisso não comunicaram.

weber

  • Expert
  • *****
  • Mensagens: 516
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #40 Online: Agosto 31, 2011, 08:30:59 pm »
Já fez esse teste?
Desde que me deparei com esse problema na versão 4 passei a tomar masi cuidado com relação a isso, recentemente não testei, mas se mexeram nisso não comunicaram.

Ta haroldo e desde quando a nm avisa alguma coisa, eu estou esperando uma resposta sobre duas solicitacoes que abri na epoca que tinha suporte ha mais de 6 meses hoje nem tenho mais acesso para ver tais tickets ....

ricardo.resende

  • Novato
  • *
  • Mensagens: 27
Re:Bugs que não devem ser transferido para versão 6
« Responder #41 Online: Setembro 01, 2011, 11:34:57 am »
Já fez esse teste?
Desde que me deparei com esse problema na versão 4 passei a tomar masi cuidado com relação a isso, recentemente não testei, mas se mexeram nisso não comunicaram.

Acabei de fazer um teste aqui... e ele faz o seguinte

Dados originais (Exemplo)
Nome da Mãe = "Maria"
Nome do Pai = "João"

(1) Estação 1
Localiza o registro

(2) Estação 2
Localiza o registro

(3) Estação 1
Altera o nome da mãe para "Maria da Silva"

(4) Estação 2
Altera o nome do pai para "João Gomes"

(5) Estação 1
Salva o registro

(6) Estação 2
Salva o registro

(7) Situação do registro após os eventos
Nome da Mãe = "Maria"
Nome do Pai = "João Gomes"

Resumindo, o que ficou valendo foram os dados salvos por último, descartando as alterações realizadas pela estação 1.

Agora fica a pergunta, existe uma forma de controlar isso pelo scriptcase??? avisando no momento em que a segunda estação for atualizar o registro, que ele sofreu alteração por outro usuário???

Abs

Haroldo

  • Expert
  • *****
  • Mensagens: 6264
  • Conhecimento diminui limitações.△TFA△
    • Infinitus Web Gestão Empresarial/Gestão ITIL/Consultoria Scriptcase
Re:Bugs que não devem ser transferido para versão 6
« Responder #42 Online: Setembro 02, 2011, 11:39:06 am »
Foi exatamente o que eu disse.
Eu resolvo isso desenvolvendo uma app de formulário com controle e colocando evento ajax em cada campo para detectar se foi alterado ou não.
« Última modificação: Setembro 02, 2011, 11:51:35 am por [Infinitus Web 2.0] Haroldo »

weber

  • Expert
  • *****
  • Mensagens: 516
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #43 Online: Setembro 02, 2011, 08:06:51 pm »
Já fez esse teste?
Desde que me deparei com esse problema na versão 4 passei a tomar masi cuidado com relação a isso, recentemente não testei, mas se mexeram nisso não comunicaram.

Acabei de fazer um teste aqui... e ele faz o seguinte

Dados originais (Exemplo)
Nome da Mãe = "Maria"
Nome do Pai = "João"

(1) Estação 1
Localiza o registro

(2) Estação 2
Localiza o registro

(3) Estação 1
Altera o nome da mãe para "Maria da Silva"

(4) Estação 2
Altera o nome do pai para "João Gomes"

(5) Estação 1
Salva o registro

(6) Estação 2
Salva o registro

(7) Situação do registro após os eventos
Nome da Mãe = "Maria"
Nome do Pai = "João Gomes"

Resumindo, o que ficou valendo foram os dados salvos por último, descartando as alterações realizadas pela estação 1.

Agora fica a pergunta, existe uma forma de controlar isso pelo scriptcase??? avisando no momento em que a segunda estação for atualizar o registro, que ele sofreu alteração por outro usuário???

Abs

Oque eu faço, é algo das antigas do inicio do visual basic, quando se utilizava-se controles do tipo datasource que amarrava o registro do banco ao componentes.

Eu crio um campo na tabela tipo char, com 0 ou 1 entao é simples em um app de grid ao inves de usar a edicao padrao do SC eu coloco um botão do tipo imagem e faço o direcionamento antes de trazer o registro para a tela eu gravo o valor no campo = 1, os proximos que tentarem acessar esse registro ja bloqueio o botao update ... até que o form que abriu inicialmente seja descarregado ... voltando o valor do campo para 0

saulobborges

  • Expert
  • *****
  • Mensagens: 1392
    • SGi Sistemas
    • Email
Re:Bugs que não devem ser transferido para versão 6
« Responder #44 Online: Setembro 02, 2011, 09:16:21 pm »
Weber, matou a pau a questão.. é muito simples dessa forma e garante integridade dos dados, uma função publica anexada nas apps resolve.

Eu não vejo isso como um bug mas também não vejo como um erro, muitas vezes para garantir a integridade de nossa base de dados temos que implementar soluções caseiras, mas para resumir uma forma de não ter este tipo de problema é deixar o processamento de banco ser feito pelo próprio banco com procedures, isso seria perfeito pois aí vc estaria trabalhando com transações identificadas pelo banco, ele trava o registro até o mesmo esteja concluido e somente depois libera.

Me corrijam se estiver errado!