Limity LN a jak rozveselí

Při pravidelném čtení partnerského fóra se člověk občas musí smát (i když je to občas asi ošklivé). Naposledy jsem se skvěle zasmál při příspěvku jednoho nováčka ve fóru, který si stěžoval na hlášku „Field is too large (32K) ….“. Většinu programátorů už tato hláška asi nerozhází, tak nějak si na ní zvykli a vždy přemýšlí jak ji obejít. Leč nyní se stalo něco nového, chlapík byl trochu rozlícen a vyvolal bouři (ve sklenici vody). Hned mu začala odpovídat spousta lidí, někteří ho hrozně sepsuli za jeho tón, jiní vysvětlovali proč to tak je.

A proč to tak je? 32KB je limit pro summary buffer, který odpovídá velikosti dat, které jsou LN schopni držet pro každý řádek v pohledu (v SQL serveru 2000 je to prý pouhých 8090B na řádek). Pokud se to člověkovi zdá pro jedno pole málo, stačí vypnout IsSummary flag (NotesItem.IsSummary = false), což spousta lidí neví, ti ostatní to s gustem využívají (ovšem maximálně 64KB, víc se tam nevejde ani potom). Celým důvodem je hlavně historie – když se programovalo jádro LN, tak to tak nějak stačilo. Možná ve verzi 8 dojde k přeprogramování i jádra systému a tedy i tohoto.

Celý tento příspěvek vyvolal vlnu dalších cca 140 příspěvků, díky čemuž se z něj stal nejvíce diskutovaný příspěvek. Teď mě jenom napadá, zda bych tam také neměl napsat něco podobného – pro změnu příkaz ReadViewEntries, pomocí kterého pravděpodobně nejde načíst více jak 131 070 dokumentů – htp://server/db.nsf/view?ReadViewEntries&start=x&Count=y, přičemž xy jsou pravděpodobně proměnné typu Integer (tedy 65 535). Nebo že by to bylo jinak?

Napiš komentář, díky!

Zabezpečení used.id u roaming users

Technologie Roaming users, která byla zavedená ve verzi 6, vypadá velice zajímavě. Ale nikde vlastně není popsáno, jak jsou zabezpečeny uživatelské ID soubory. Což je asi jedna z nejdůležitějších bezpečnostních otázek. V partnerském fóru IBM se objevilo hned několik komentářů na toto téma a jsou plné informací.

Podle veškerého popisu to vypadá, že ID je dvojitě heslováno. Nejdříve uživatel musí zadat heslo, které vygeneruje klíč a odešle ho na server. Zde, pokud souhlasí heslo, server vygeneruje nový klíč na základě údajů v poli RoamingBlob a zašle ho zpět uživateli. Až poté je ID otevřeno a plně funkční, do této doby je jeho kus šifrován. IBM používá krásné spojení „Bellovin-Merritt Encrypted Key Exchange“ pro vysvětlení, jak to celé vlastně funguje.

A to je celé – člověk asi může být trochu klidnější s bezpečností i když vlastně vůbec neví jak to celé funguje. Což je na druhou stranu asi zase dobře, člověk nemusí vědět všechno.

Napiš komentář, díky!

Flat name není podporované

Není nad to, když se v dokumentaci objeví maličkosti, kterým člověk nevěnuje příliš pozornosti. Právě za takovou maličkost jsem považovall ukončení podpory pro flat name ve verzi 7. Nicméně i tato hloupost, kterou přeci nikdo nepoužívá :)), dokáže potrápit. Sám jsem tomu nevěnoval pozornost, dokud mi nezačali lidé hlásit, že z helpdesku odcházejí emaily se špatnou adresou. Někteří z našich uživatelů totiž přistupují k LN pouze pomocí webu a nebyl důvod je registrovat klasickým způsobem – místo toho jsme zakládali pouze jejich person dokumenty v adresní knize a tam nedávali jméno v hierarchickém formátu (tedy včetně certifikátu).

Ve verzi 6 fungovalo vše v pořádku, při odesílání emailu agentem (který byl spouštěn z webu a běžel pod přihlášeným uživatelem) došlo ke správnému nalezení emailové adresy a odeslání emailu pod korektní adresou. Ve verzi 7 ovšem došlo ke změně – díky ukončení podpory pro flat name se změnila i tato maličkost. Najednou nedocházelo k dohledání emailové adresy v person dokumentu člověka a emailová adresa se vypočítávala ve tvaru Jméno%Příjmení@firma.cz (a možná ještě horším). Poté co jsem do fullname u těchto uživatelů zapsal i certifikát (neregistroval jsem je znovu) tak bylo vše v pořádku.

Napiš komentář, díky!

Proč programovat v Lotus Notes

Partnerské fórum je plné zajímavých článků a informací. Nedávno se probírala i otázka, proč je člověk business partnerem a jedna z odpovědí byla i ta, že daný člověk je nera mrtvou rybou, která plave s prodem (i když v angličtině to zní výrazně lépe :)). Ale nedlouho poté Rudi Knegt z RKJSOFTu napsal tento krásný článek, který nechávám v angličtině (a který mám pocit, že je více než pravdivý).

Continue reading

Napiš komentář, díky!