Opa Jair tem o link do API terceiros, de banco?
a empresa utiliza externo a accesstage : https://site.accesstage.com.br/
mas, como falei, existem alguns bancos que já tem os próprio EDI, é bom ver antes se o banco fornece a solução a custo zero
Chocado…como podem persistir com tantos erros básicos de atendimento após tantos anos de mercado?
Simples Wagner. Os usuários toleram está situação e continuam comprando ou renovando as licenças.
Se tem dinheiro entrando para que a Netmake irá mudar?
2 Curtidas
Qual seria a solução?
Através dos anos tivemos nossas vozes silenciadas pela falta de respostas ou a política interna da Netmake.
Se há única linguagem que uma empresa entende é o faturamento.
Então, por exemplo, os usuários de Scriptcase devem se reunir em torno de uma meta.
Ninguém renova as licenças até que tenhamos voz ativa.
Principalmente na Black Friday que está chegando.
Envie e-mail dizendo: Não renovarei até que sejamos ouvidos e as políticas da empresa sejam mudadas.
Deve-se ter uma pauta seria do que deve ser mudado e todos enviarem o mesmo e-mail.
Sem renovação até que sejamos atendidos.
E realmente ninguém deve renovar.
2 Curtidas
Bom dia a todos, não renovei a licença este ano porque estou quase perdendo um cliente que usa esta ferramenta como base. Os totais de grid não batem, comportamentos erráticos, bugs que vão e vem, entre outras coisas minaram a confiança do Cliente e a minha. Infelizmente já iniciei um projeto para migrar para outras frames mais leves e modernas. E uma pena porque gostaria de incentivar a indústria nacional de software mas não posso fazer isto ao custo de clientes.
@HenriqueB @yuri_esteves @marcia.scriptcase @PedroLucas
Avaliem o nível do suporte e me digam se vale a penas usar o Scriptcase?
Vídeo onde demonstro o problema:
Liberar o open_basedir é um grande furo de segurança no caso dos meus servidores, ok?
Eles se recusam a consertar esta situação.
Para eles é normal o Scritpcase procurar arquivos que não existem.
1 Curtida
@buhlerax . Pelo visto o suporte não tem interesse nessa correção, talvez por causa que servidor de hospedagem deles tenha um ajuste específico não ocorrendo o erro. Mas quem hospeda em outros servidores não tem a possibilidade desse ajuste. Isso força o uso dos servidores deles.
O problema é claro, obvio e perigoso. Mas vejo desinteresse em dar atenção a esse problema.
2 Curtidas
@HenriqueB @yuri_esteves @marcia.scriptcase @PedroLucas @InfinitusWeb
Acaba sendo algo que tenha que recorrer ao reclameaqui.
O Scriptcase acaba sendo um produto que não pode ser usado em qualquer lugar como outros frameworks. Pois dá erro, coisa que outros frameworks não fazem
2 Curtidas
@HenriqueB @yuri_esteves @marcia.scriptcase @PedroLucas @InfinitusWeb
Definitivamente enquanto colocar a segurança do servidor em risco o Scriptcase não vale a pena ser usado!
https://www.reclameaqui.com.br/netmake-scriptcase/pedem-que-eu-baixe-a-seguranca-do-servidor-para-que-o-scriptcase-funcione_HuXrWcp0RjwKQKCI
Olha, não sei o por que utilizar a open_basedir como parametrização de segurança.
Pois, se for assim, a shell_exec ativada trás mais riscos.
Basta passar args com Shell , que você consegue criar até contas no servidor, caso sua segurança não esteja bem configurada, e não vai ser um open_basedir vazio ou com valor que vai impedir .
E convenhamos que se a open_basedir fosse confiável o cPanel e Plesk utilizariam essa opção, porém, não usam. Esses aplicativos utilizam um tipo de segurança totalmente diferente e confiável a nível SO.
Pa.: Citando cPanel e Plesk por serem as empresas conceituadas no ramo em questão.
1 Curtida
@MarcoRuben @ MNiceas
Servidores sérios tem o shell e a execução de qualquer coisa nele enjaulando. Então pode executar o que quiser com o shell_exec que não ira abalar todo o servidor. Ok?
Somente será abalado o diretório da hospedagem do cliente.
Não somos tolos. Provedores sérios não baseiam sua segurança somente no open_basedir.
Nosso ponto é que o Scriptcase não está 100% com o open_basedir ativo.
@ MNiceas @MarcoRuben
Mais uma coisa pode ver que neste post:
Tive a hospedagem do meu Scriptcase invadido. Mas usando a mesma configuração de segurança que hoje gera os erros descritos. Somente eu fui afetado. Os outros usuários do servidor não tiveram sua segurança comprometida.
E foi por furo de segurança no Framework.
Não quero que meus usuários ou eu passem atualmente por isto por causa de open_basedir desabilitado.
Pois , foi exatamente isso que falei.
Você citou que em seus servidores liberar o open_basedir é um grande furo de segurança.
Mas agora citou que provedores sérios não se baseiam apenas no open_basedir.
Então, não vejo o por que, de uma configuração a nível de PHP interferir na segurança do servidor, se o cloud Linux (cPanel) como já citado, deixa essa diretiva a nível do PHP vazia, e mesmo assim , qualquer invasão , caso exista, afetará apenas o diretório do usuário em questão. Mesmo que, volto a frisar, a open_basedir esteja vazia.
Assim, podemos concluir que a open_basdir não é um item essencial para aumentar ou diminuir a segurança , mas sim como o servidor está configurado a nível de SO para, como você citou, enjaular a conta do usuário.
Concluindo que ter ou não a open_basedir com valor em um servidor depende da escolha do SysAdmin, e do aplicativo utilizado para controle de contas de usuário e acesso Web.
Que por opinião minha, utilizar o cPanel ou plesk seria uma medida mais confiável e segura do que se basear em aplicativos que dependem da open_basedir para controle de acesso ao arquivos via web.
@MarcoRuben @ MNiceas
Marco a questão de segurança somente prolongaria a discussão e não faria a correção necessária no Scriptcase. Ele tem que funcionar com ou sem o open_basedir ativo. Outros Frameworks funcionam normal aqui com o open_basedir ativo. Não posso citar quais ou acabo expulso do fórum por ferir as regras. É tão complicado pedir que o Scriptcase deixe de procurar arquivos que Não existem? Ele forma caminhos para arquivos que somente podem ser erros de programação. Veja meus vídeos no youtube por favor.
PS: Cpanel
https://documentation.cpanel.net/display/82Docs/PHP+open_basedir+Tweak
Overview
The open_basedir tweak limits the user’s ability to browse the file system with PHP. It prevents PHP’s access to the user’s home directory, the / tmp directory, and some necessary PHP system directories. This helps to protect your system from unauthorized access through PHP.
Tradução:
visão global
O ajuste do open_basedir limita a capacidade do usuário de navegar no sistema de arquivos com PHP. Impede o acesso do PHP ao diretório inicial do usuário, ao tmp / tmp e a alguns diretórios necessários do sistema PHP. Isso ajuda a proteger seu sistema contra acesso não autorizado através do PHP.
Plesk:
It is possible to do that, however, there is always a risk for code to be compromised, which will lead to the bigger damage if open_basedir parameter is set to none instead of webspace root.
Tradução: É possível fazer isso, no entanto, sempre há um risco de comprometimento do código, o que causará maiores danos se o parâmetro open_basedir estiver definido como none vez da raiz do espaço da web.
Bom relato, explicando que existem essas propriedades, como eu citei, no cPanel e Plesk.
No entanto, a diretiva open_basedir não protege contra alguém que possa executar o código (PHP) no servidor.
- Por exemplo, simplesmente executar a função system(‘cat/etc/passwd’) ignorará a configuração do open_basedir. Além disso, nem todas as funções que manipulam arquivos verificam o caminho que está configurado nesta diretiva.
Ou seja, como eu já tinha citado anteriormente, a open_basedir não é um item essencial para aumentar ou diminuir a segurança em um servidor.
Tanto que, utilizando-se do cPanel, é possível alterar este item através do PHP Selector, pois o PHP Selector roda sobre o CageFS , o qual tem uma tecnologia a nível de SO para “enjaular” o usuário do cPanel, diferente do open_basedir que possui a tecnologia a nível web(PHP).
Por exemplo:
If CloudLinux + CageFS is installed (suPHP / suexec environment) and CageFS is enabled for all users,
then all PHP/CGI requests (suPHP / suexec) are processed through the users’ cage
For caged users, it doesn’t matter if open_basedir is set or not, since PHP processes will not be able to break out of /home/
Se o CloudLinux + CageFS estiver instalado (ambiente suPHP/suexec) e o CageFS estiver ativado para todos os usuários, todas as solicitações PHP/CGI (suPHP suexec) são processadas na “jaula dos usuários”.
Para “usuários enjaulados”, não importa se a open_basedir está definida ou não, pois os processos PHP não poderão sair de /home/
Assim, me parece que a open_basedir trás uma sensação de falsa segurança.
Particularmente, eu uso o Scriptcase(RAD) em um servidor de hospedagem compartilhada ( não vou citar nomes, pois vi que você falou sobre regras do forum ).
Este servidor utiliza o cPanel, e sem restrição na open_basedir.
Nunca tive problemas com invasão ( tanto a nível de falha de bibliotecas, quanto a nível de SO ).
@MarcoRuben @ MNiceas @HenriqueB @yuri_esteves @marcia.scriptcase @PedroLucas
Cansei a Netmake venceu.
Desejo sorte aos usuários da ferramenta.
Você conseguiu alguma resposta (nova/recente) da NetMake sobre este caso?
- Pensei que estávamos debatendo sobre o impacto da open_basedir em servidores que utilizam o ScriptCase.
Hoje, eu consegui ficar mais ativo nesse fórum, e vi que você tinha colocado uma postagem (acho que bem antiga, mas tava na minha lista de recentes ) sobre a deleção de postagens, o qual era uma desserviço afronta.
Mas, opiniões mudam com o tempo.
- A troca de conhecimentos foi construtiva.
1 Curtida
