Errore di sicurezza sul sistema asp.net dopo la distribuzione di bug fix dll [closed]

1

I (recentemente ereditato) un'applicazione web asp.net in produzione. Dopo aver corretto un bug generico nell'area di selezione di una tabella, abbiamo un problema riguardante le politiche di sicurezza che non consentono l'accesso a un determinato x plugin attivo.

Il nostro cliente è riluttante a consentire le autorizzazioni (questo ha risolto il problema nel nostro ambiente di test). Persistono che questo non era necessario prima della distribuzione della nostra supposta correzione, e che non dovrebbe essere necessario per loro cambiare le loro impostazioni di sicurezza, poiché stava funzionando bene prima della distribuzione della correzione.

La correzione in realtà non ha nulla a che fare con le autorizzazioni e, naturalmente, ora vorremmo capire meglio il problema, prima di prendere una decisione su cosa fare dopo.

Penso che forse ha qualcosa a che fare con i parametri di costruzione, come le versioni del compilatore usate. O che potrebbe avere qualcosa a che fare con le impostazioni ambientali (64 bit contro 32 bit).

Non ho idea di dove cominciare, o cosa confrontare. C'è uno strumento che può essere usato per confrontare le impostazioni del compilatore utilizzate per creare una DLL? (le modifiche erano in una DLL).

    
posta Harriet 24.05.2016 - 12:31
fonte

1 risposta

0

Our client is reluctant to allow permissions ...

Come è giusto.
Non hai il mandato di dettare le impostazioni di sicurezza che il tuo cliente "deve" utilizzare.

... this has fixed the problem on our test environment

Sbagliato!
Questo ha solo mascherato il problema perché il problema esiste ancora sul sito del tuo cliente e, ammettiamolo, questo è il posto solo che conta.

Tu devi avere un ambiente di test rappresentativo, cioè lo stesso del tuo sito [s] dei tuoi clienti, oi tuoi test sono praticamente privi di valore.

They persist that this was not necessary before deployment of our supposed fix ...

"Risoluzione supposta". Interessante frase. O forse la consapevolezza che il tuo cambiamento non era la cosa giusta da fare.

... and that it should not be necessary for them to change their security settings ...

E sono assolutamente giusti.

Hai apportato una modifica al codice che rettifica il difetto segnalato (sulla selezione della tabella) ma hai introdotto un nuovo difetto in base al quale il tuo codice non è conforme al cliente scelto impostazioni di sicurezza.

The fix really have nothing to do with permissions

Forse no, ma ha introdotto un nuovo difetto che chiaramente fa .

we would like to better understand the problem, before making a decision of what to do next.

Non hai molta decisione da prendere.

Trova un'altra correzione per il problema di selezione della tabella che il cliente è felice di accettare.

I am thinking that maybe it has something to do with build parameters, such as compiler versions used. Or that it might have something to do with environmental settings (64 bit vs 32 bit).

No; Guarderei prima quell'ActiveX Control.

hai introdotto questo controllo come parte della tabella "fix"? Se è così, questo è quasi certamente il tuo problema. Se era lì prima della "correzione", allora hai altri problemi.

I have no idea of where to start, or what to compare.

Non usi uno strumento Controllo del codice sorgente per registrare tutte le modifiche apportate al tuo codice sorgente? File di progetto?

Is there a tool that can be used to compare compiler settings used to create a dll? (the changes was in a dll).

Praticamente ogni prodotto di controllo del codice sorgente sul pianeta viene fornito con una sorta di strumento di confronto delle versioni.

Se non li stai utilizzando, allora stai davvero volando vicino ai pantaloni.

    
risposta data 24.05.2016 - 13:24
fonte

Leggi altre domande sui tag