progamma/cloud-connector

cloud-connector's Issues

Sicurezza Cloud Connector

Non inviare SID ma tenerlo dentro al server dal lato della socket. Usare cbID per identificare chi ha fatto quella query e “ricollegare” domanda e risposta.
Creare CloudConnectorKey a design-time (in campo read-write prefillato con GUID36 e verifica formale del valore per fare in modo che il programmatore non possa cambiarlo con “pippo”).
Inviarlo nelle query e, lato server, cercare il cloud connector per chiave e non per name. Trovato quello buono uso quello per fare la query.

Lato IDE eliminare dalla combo tutti i CC che non hanno il CCK corretto (così evito la combo pollution)
Assegnare ai messaggi in uscita un callbackID (non predicibile... GUID36). Tenere (dentro al sever) una mappa callbackID -> SID. Quando arriva la risposta cerco la SID con quel callbackID e fornisco la risposta alla sessione giusta

Limitare i log

Balestrieri nel ticket 002303-2023 segnala che i log crescono in fretta.
Si potrebbe pensare di limitarli in qualche modo.

ActiveDirectory: TypeError: Cannot convert undefined or null to object (workaround)

Verificando con un cliente di Pro Gamma l'uso del plugin ActiveDirectory ci siamo imbattuti in questo issue del plugin.

La cosa è risolvibile con un override nel package.json:
"overrides": { "activedirectory": { "ldapjs": "2.3.3" } }

Ho pensato di aggiungere questa issue per segnalare il workaround anche ad altri che possono aver avuto lo stesso problema, oppure per valutare una modifica a questo repo.

Errore nella documentazione in README.md

Installando la versione 22.5 di Cloud Connector ed utilizzando Node.js in versione 12.17.0 come indicato dalle istruzioni di installazione quando si manda in esecuzione CloudSevber.js si riscontra il seguente errore:

C:\idc\public_html\cloudServer.js:268
  config.datamodels?.forEach(dm => this.createDataModel(dm));
             
SyntaxError: Unexpected token '.'
←[90m    at wrapSafe (internal/modules/cjs/loader.js:915:16)←[39m
←[90m    at Module._compile (internal/modules/cjs/loader.js:963:27)←[39m
←[90m    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)←[39m
←[90m    at Module.load (internal/modules/cjs/loader.js:863:32)←[39m
←[90m    at Function.Module._load (internal/modules/cjs/loader.js:708:14)←[39m
←[90m    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)←[39m
←[90m    at internal/main/run_main_module.js:17:47←[39m

Utilizzando la versione 16.4.2 di Node.js funziona.
Occorre modificare README.md per indicare una versione minima diversa.

Riconnessione automatica

Al momento se si perde la connessione verso un server non c'è nessun automatismo di riconnessione.

File non chiusi dopo apertura in lettura

var f = fs.file();
yield f.open();
yield f.close();
yield f.remove();

Il file non viene eliminato fino al termine del processo perché la close non chiude rstream.

Chiusura file aperti alla disconnessione di un server

Se un server si disconnette mentre stava scrivendo un file il file rimane aperto.

Vedi progamma/IndeRT#4343

Connessione verso https self-manged con let's encrypt

Collegandosi ad un server di produzione self-managed con certificato https di let's encrypt (con altri non abbiamo provato) si ottiene "transport error: 503" nell'apertura della socket.

Per aggirare il caso è stato necessario impostare opt.rejectUnauthorized = false nella Node.Server.prototype.connect.

Può valere la pena metterlo dentro come parametro di configurazione o simili? Oppure ce ne dimentichiamo perché il problema si è posto una volta sola?

@andreamaioli @matteosirri che ne pensate?

Aggiornamento pacchetti

Aggiornare i moduli.

DM Conversione errata colonne calcolate

vedi issue di IndeRT https://github.com/progamma/IndeRT/issues/2897

Connessione a MySQL 8

In MySQL 8 hanno introdotto un nuovo sistema di autenticazione.
Il modulo mysql ancora non supporta la nuova modalità (mysqljs/mysql#1507).

Al momento occorre utilizzare un utente con la vecchia modalità di autenticazione.

Connessione a SQL Server e versione TLS

Tra le possibili proprietà che si possono usare per configurare il cloud connector c'è anche la proprietà options.encrypt che, se non impostata, vale true.
Se non si specifica il contrario, quindi, la connessione è sempre cifrata usando il protocollo TLS.
Le versioni più recenti di node accettano solo il protocollo TLS1.2 perché le versioni precedenti, TLS1.1 e TLS1.0, sono deprecate ma le versioni di SQL Server dalla 2014 12.0.4439.1 in giù non supportano o non usano di default la versione 1.2 di TLS.
Quindi in base alla versione di SQL Server utilizzata non si riesce ad instaurare la connessione e si può ottenere l'errore: "Cannot call write after a stream was destroyed".

Per sapere quale versione di TLS usa una specifica versione di SQL Server e come si può aggiornarla, si può consultare questo link:
https://support.microsoft.com/en-us/help/3135244/kb3135244-tls-1-2-support-for-microsoft-sql-server