[RESOLVIDO] - App login erro variável $slogin

Bugs
#1

Olá pessoal.
Tenho um projeto que faz uns 5 meses que não houve necessidade de alterar ele feito na 8.0.
Código da Aplicação->seg_appp_Login (8.00.0015)->Código da aplicação para uso interno do ScriptCase.
Hoje precisei dar uma atualizada no projeto e ao tentar executar a app de login em desenvolvimento apareceu o seguinte erro:
Parse error: syntax error, unexpected ‘=’ in C:\NetMake\v81\wwwroot\scriptcase\app\pasta_projeto\seg_appp_Login\seg_appp_Login_apl.php on line 1626
Ao checar o código fonte me deparei com as seguintes linhas:

if (!isset($this->sc_temp_usr_email)) {$this->sc_temp_usr_email = (isset($_SESSION['usr_email'])) ? $_SESSION['usr_email'] : "";}
if (!isset($this->sc_temp_usr_name)) {$this->sc_temp_usr_name = (isset($_SESSION['usr_name'])) ? $_SESSION['usr_name'] : "";}
if (!isset($this->sc_temp_usr_priv_admin)) {$this->sc_temp_usr_priv_admin = (isset($_SESSION['usr_priv_admin'])) ? $_SESSION['usr_priv_admin'] : "";}
if (!isset($this->sc_temp_usr_login)) {$this->sc_temp_usr_login = (isset($_SESSION['usr_login'])) ? $_SESSION['usr_login'] : "";}
               slogin = $this->Db->qstr($this->login );
$spswd = $this->Db->qstr(md5($this->pswd ));

A linha com o erro é essa:

slogin = $this->Db->qstr($this->login );

Que o correto seria:

$slogin = $this->Db->qstr($this->login );

Essa variável é criada automaticamente pelo SC se eu não estiver enganado.

#2

Tentou recriar um plano de senha ‘novo zero’ na SC 8.1 atual? para ver se o erro continua? porque o plano de senha uma vez gerado ele não é mais atualizado ‘gerado os códigos novamente dos (eventos)’ apenas é gerado compilado igual se fosse uma app normal do resto do projeto.

#3

Não fiz nada disso.
Para fazer isso tenho que gerar toda parte de segurança novamente?

#4

Sim, copia as tabelas atuais da segurança e apps exporta e guarda e refaz novamente, para ver.

#5

Esse era o meu medo.
Assim vai resolver mesmo já que hoje estou criando projetos e esse erro não ocorre.
Vai ser uma trabalheira, e esse erro está sujeito a recorrência em um futuro próximo lá pelas 8.1.30, 8.1.32, 8.2, 9.0… enfim.
Já nesse projeto feito na 8.0 e que está nativo e gerado novamente na 8.1… e esse erro aparece o que não deveria.
Supostamente se o projeto está no SC e o SC vem se atualizando o projeto uma vez gerado deveria atualizar também ou no minimo permanecer no estado em que se encontrava ou seja funcionando.
Transtorno gerado visto que tenho códigos e personalizações e campos criados na tabela do user por exemplo idEmpresa etc.
Tudo isso terá que ser refeito por causa de erro tosco.
Se eu gerar o projeto e subir ele vou até o código fonte e insiro o “$” e ele passa a funcionar.
Mas daí já sai do propósito que a ferramenta me proporciona que seria a integridade do projeto uma vez que ele nunca foi retirado da minha área de projeto.
Erros acontecem e estamos aqui para tentar resolver ainda mais em se tratando de uma ferramenta RAID e o cliente esperando uma resolutividade de nossa parte.

#6

Sim igual o LINUX, de uma release para outra, eles as vezes decidem que fazendo do jeito X não tá legal e mudam para o Z que fica melhor mais rápido, mais bonito, etc, ai tem quebra de códigos legados, até quando eu usava UBUNTU a Canonical, eles recomendavam fazer o backup e na nova release instalar do zero para não ter problemas de compatibilidade e aproveitar melhor os novos recursos.

#7

Eu que o diga Jailton,
Odeio trabalhar com CentOS pelo fato que uma vez peguei um CentOS para atualizar o php. De forma que o cliente pudesse rodar o scritpcase.
Era um servidor de produção. O CentOS era tão velho que simplesmente os repositórios extra oficiais não funcionavam mais.
Não consegui nenhum repositório com o php 5.4 necessário para rodar o scritpcase.
Enfim melhor solução fazer upgrade de distro. Na época para 6.
e usar o repósitorio:
CentOS/RHEL 6.x:

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el6/latest.rpm

Ai me deparei com isto:

https://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.0
"Similar to the practice of the upstream vendor, there is no supported path to ‘upgrade’ an installation of a prior major CentOS release (presently CentOS 5 or CentOS 4) to a new major release. This is not a CentOS imposed limitation, but rather reflects the upstream’s approach on this matter. People who feel adventuresome and want to experiment are reminded to take and test backups first. As a note to people who attempt the upgrade in spite of this warning, such as by the unsupported upgradeany option from the media install command line, please note that you will need to manually retrieve the current centos-release package, manually do a rpm -e --nodeps removal of the prior centos-release package, and then manually install the CentOS 6 centos-release package, before yum can have any chance of working properly. "

Ou seja, diferente do Debian e Slackware a possibilidade de quebra era grande.
Resultado: Instalar o compilador c e suas dependências através da mídia e compilar o php.

Enfim, não importa onde ou quando. As leis de Murphy sempre irão te ajudar.

#8

Acesse o evento “OnValidate” da aplicação de login e verifique se a variável “slogin” está com “$” ao lado do campo.

$slogin = sc_sql_injection({login});
$spswd = sc_sql_injection(md5({pswd}));

O código sempre foi gerado desta forma.

Por acaso foi feita alguma alteração nos evento dessa aplicação?

#9

Caro Yuri,
Faltava o $.
Obrigado.