Měl bych otázku ohledně šifrování hesel...

v současné době to máme v našem frameworku tak, že se vezme login, heslo, pro každý zvlášť se udělá následující funkcí MD5 hash, odstraní se pomlčky a spolu se to uloží do DB oddělené pomocí rovnítka - |.

public static string GetMD5Hash(string aValue)
        {
            MD5 md5Provider = MD5CryptoServiceProvider.Create();
            Byte[] valueBytes = Encoding.Unicode.GetBytes(aValue);
            Byte[] hashBytes = md5Provider.ComputeHash(valueBytes);
            return (BitConverter.ToString(hashBytes)).Replace(MD5_HASH_DELIMITER, String.Empty);
        }

Co byste doporučili jako náhradu za MD5? Providerů v System.Security.Cryptography je mraky, AES, SHA256 atd.
Tu logiku se spojenými hashi bych asi zachoval, ale MD5 jaksi není hodné roku 2016. Díky

MORMEGIL: jo taaak...

VIRTUALVOID: Tak on píše, že je chce _stáhnout_, ne zobrazit.

PEPSIN: tak ja neviem, ale byt prehliadac tak ti octet-stream nezobrazim ako obrazok :) skus mu posielat to co naozaj mas... minimalne z toho nazvu suboru sa da mime-type zistit.

kazdopadne ak sa naozaj jedna o mvc app, a vracias to von z controllera, tak by som rozmyslal o niecom takomto:

public ActionResult Metoda()
{
 ...
  return File(ms.GetStream(), "image/jpeg");
}

VIRTUALVOID: VIRTUALVOID: Tak headery vypadaji tak nejak takhle

Cache-Control: private
Content-Length: {delkaSouboru}
Content-Type: application/octet-stream
Content-Location: traslasierra_16to10.jpg
Content-Disposition: attachment; filename*=UTF-8''{jmenoSouboru}
Content-Transfer-Encoding: binary

VIRTUALVOID: No to je mozny, ale v tom pripade mi osvetli jak je to dobre. (a proc to pro jine prohlizece funguje a pro IE jen obcas)


VIRTUALVOID: hmm mrknu, ten tam skutecne nejspis neji (je tam jen content-disposition attachment... a par dalsich, ale tenhle ne)

imho to s tym streamom nedelas dobre jaromire

Zdravim mistni odborniky, mam dalsi dotaz ohledne jednoho ASP MVC projektu.

Potrebuju stahnout obrazky a to budto v puvodni velikosti a nebo resizovane. V puvodni velikosti pouziju proste:
response.AppendHeader("Content-Length", file.Length.ToString());
response.TransmitFile(file.PhysicalPath);

To neni problem. Problem je kdyz je potrebuju resizovat. I to umim, vysledkem je obrazek v pameti. Problem ale nastava v jeho odeslani. Pouzivam nasledujici konstrukci, (resizedImg je typu Bitmap)

using (MemoryStream ms = new MemoryStream())
{
using (var resizedImg = ResizeImage(img, (int)newWidth, (int)newHeight))
{
resizedImg.Save(ms, OriginalFormat);

}

response.AppendHeader("Content-Length", ms.Length.ToString());
ms.WriteTo(response.OutputStream);
}
Vetsina prohlizecu s tim nema problem, ale v IE (v 11) to z nejakeho duvodu obcas jde a obcas ne. Pritom ve Fiddleru vidim ze se ty data prenasi.

Setkal se s timhle uz nekdo? Na internetu sjem nasel mraky navodu, od nastavovani cache pro IE pres jinou konstrukci odesilani (vetsinou konstrukce vyndejte reposne.flush a a dejte tam context.HttpContext.ApplicationInstance.CompleteRequest(); ) nic z toho nepomaha. Mohl by me nekdo nasmerovat do nejakeho smeru jak to resit, a nebo aspon poradit nejakou metodiku jak to troubleshootit?

TOOMIX: MEMNON666: PJOTRIK:

Vsem diky za odpovedi. Momentalne jsem se prave dostal k tehle fazi, vycistit biny, dat clean project a doufat. Na netu jsem nasel ze to muze byt (mimo jine) spatnym nastavenou build akci na XAML main page (ten tu neni, protoze Caliburn, a nemam tuseni jak by se mohl menit ale i tak je to zajimavy smer). Bohuzel jsem momentalne v situaci kdy vse bezi a me se nedari zaboha chybu vyvolat. Pokud na neco prijdu, hodim to sem.

PEPSIN: co úplné smazání bin a obj adresážů a následný rebuild všeho?

PEPSIN: s necim podobnym jsem se potkal po padu visual studia, pak az po novem nacteni z gitu sem projekt rozchodil ale to ti asi moc nepomuze :D

PEPSIN: Potkavam se s tim teda v dost jinych situacich (jediny v cem se shoduji je VS2015), ale podobny situace kdy zacne build nebo prubezna analyza kodu hlasit nesmyslny chyby se mi obcas stanou a jediny co jsem nasel ze pomaha je smazat .vs adresar

Ahoj ve spolek
mam dotaz, na divnou chybu ktera se mi objevuje a ja nevim co s ni, jestli jste se s tim uz nikdo nesetkal.

Mam projekt co jede na Visual studio 2015, Je to WPF aplikace a obsahuje caliburn. K finalnimu vytvoreni MSI se pouziva WIX, ktery je v solutione zahrnuty jako projekt. Realne buduju jen 4 kombinace (Release x64, Releaase x86, Debug 86 a Debug 64), nepouziva se anyCPU.

Stava se to ze kdyz clovek vybuduje projekt, a prepne nstaveni na jine (reneme na R64, je to nahodne), objevi se nahodne chyby v projektu. Build jako takovy jede az do Setup Projectu, tam wix zfailuje (ale binarky vypadnou a jsou fajn). Chyby ktere se objevuji vypadaji dost podivne. Ve tridach najednou nelze najit buttony napsane v XAMLu, zdedene funkce zeshora nejsou k nalezeni, trosku to zavani caliburnem (ne nutne). Setkal se nekdo s necim podobnym?

Zatim se mi nejenom nepodarilo najit symptom, ale ani se mi nepodarilo najit workaround, obcas to proste blbne a obcas ne, a to je ve chvuli kdy potrebujete vyhodit msi k testovani proste na pikatchu.

Používali jste někdo code annotation atribute od Jetbrains? Jaké máte zkušenosti z praxe? Vyplatí se to?

Je tady nekdo, kdo hackuje CoreCLR?

H_U_N_T_E_R: hodně mi tam chyběly letos představené věci jako třeba Bot Framework, Azure Functions ale zase se tam opakovaly přednášky jako Diagnostické nástroje v Azure a Logování a monitoring - přišla mi škoda zaplnit program přednáškama z WUGu. Ale určitě díky za akci, jenom bych vylepšil ještě tohle :-)

Po tom, co vyšlo Visual Studio 2017 RC, netušítě někdo, kdy má vyjít final verze? Budeme ve firmě povyšovat z VS2012, tak jestli koupit 2015 nebo chvíli počkat na 2017