Author: Merike

Posted on

Thunderbird ja Gmaili prügikast imapiga

Ehk on järgnev kellelegi abiks aja kokkuhoiul.

Hoiatus: ebaõnne(stumise) korral võib konto muutuda nähtamatuks või juhtuda muud imelikku/ehmatavat. Enne proovimist tee oma profiili kaustast koopia: kuidas seda leida.

Kui Thunderbirdi Gmaili imap konto lisada ning Thunderbird on inglise keeles ja Gmail eesti keeles, siis on tulemuseks kaks prügikasti, Gmaili enda oma ja Thunderbirdi Trash. Samuti ei ole sünkroonis rämpsposti, saadetud kirjade ja mustandite kaustad. Järgnevad seaded panin paika enne eesti keele paketi lisamist, kuid et Thunderbird enam inglise keele peale minna ei taha, pean valikud eesti keeles kirja panema.

Rämpspost – konto rämpsposti sätete juures on valik, kuhu uued rämpskirjad liigutatakse. Valikule linnuke ette ja samuti valida muusse kausta ning sealt sinu_konto_nimi > Gmail > Rämpspost. Kui edaspidi meili rämpsposti alla lisate, uuendab ka Google selle põhjal omi teadmisi rämpsposti saatjate kohta ning meilid peaks ka veebiliideses õigesse kausta liikuma.

Sarnane lugu on ka saadetud kirjade ja mustanditega. Konto sätete juurest “Koopiad ja kaustad” ja sealt edasi mõlema puhul valik muu ning sinu_konto_nimi > Gmail ja siis “Saadetud kirjad” või “Mustandid”.

Prügikasti jaoks tuleb ette võtta konfiguratsiooni redaktor. Selleks tuleb lahti võtta Thunderbirdi eelistused ning sealt muud > üldine > konfiguratsiooni redaktor. Avaneb aken pealkirjaga “about:config”. Filtriks võib panna “mail.server.s” ning üles tuleb otsida väärtuste tulbast oma konto nimi ning jätta meelde selle number vasakus tulbas, nt mail.server.server1.name puhul on see 1. Edasi paremklõps mõnel kirjel ja sealt uus > string. Esimesena avanevasse lahtrisse tuleb panna mail.server.server1.trash_folder_name oma numbriga ja järgmisesse [Gmail]/Prügikast. Mõnedes allikates on kirjas, et täpitähti ei tohi otse kirjutada vaid tuleks ära kodeerida, kuid proovimise käigus töötas ainult otse nende sisse kirjutamisega variant.

Seejärel võib Thunderbirdi kinni panna. Veebiliidesest tuleks kustutada ära silt nimega [Imap]/Trash ning ühtegi teist prügikasti moodi silti ei tohiks samuti olla, kui te pole neid just eelnevalt veebiliideses loonud. Pärast seda võib uuesti Thunderbirdi avada ja hea õnne korral loksuvad kaustad vasakul puus ise paika. Natuke halvema õnne korral tuleks oma konto haru puus kokku-lahti teha ja proovida võib teistkordset Thunderbirdi taaskäivitamist. Lõpuks võiks pilt olla selline:

Gmaili imap kaustapuu Thunderbirdis

Kontrolliks võite proovida “Saabuvad” kaustas kirja kustutamist. Kiri peaks liikuma kausta “Prügikast” ja prügikasti tühjendamisel Thunderbirdis peaks kiri jäädavalt ka veebiliidese prügikastist kustuma.
Kõik kirjapandu peaks töötama Thunderbirdi versiooniga 2.0.0.14.

Posted on

Never trust server’s time for your own sake!

I’ve just had another very useful lesson on what to not do. In one of my school project I have one table in database that represents orders and another that keeps events associated with orders. The latter one simply has an foreign key to order table. Each event has timestamp and a number that references order state after the event. State is stored as a number and it references third table which keeps all numbers with their respective states. To find out which is the current state of an order you simply run a query that selects all events associated with that order and finds out which one is the newest.
Turns out, that’s exactly how not to design a database! While we were showing off our work to our lecturer the strangest thing happened, after he confirmed an order it stayed in the same state as before! Very bad considering that every time an order is confirmed the number of products in warehouse is increased by the amount in the order by application. Confirming the same order more than once is something that should not be possible! And our application did have a check whether the order in a state that allows the next state to be “confirmed”.
My first suspect was the type of event that is inserted would be wrong. We had one such case with the same project earlier. Stupid, but yes, that’s exactly why you need to test everything. That was not the case, quick look on tables showed that this part was correct.
Next was the probability that the database view that displayed each order’s state was incorrect. That was a rather complicated query compared to simple select clause and I didn’t really feel like debugging it. Instead I took another look at the events table. This time I paid attention to the timestamp attribute as well. Imagine my surprise when I saw that the timestamp for the last event was 40 minutes earlier than the event that I know had happened earlier! Apparently while the lecturer was clicking around, confirming orders and such, our lovely server decided to go back in time by 40 minutes!
I wouldn’t have come to that conclusion unless the time wouldn’t be incorrect at the moment.
Simple script echoing time showed 18:05:59 and three seconds later 18:05:02! It was actually about 18:50.
My lesson from this: if you want to keep events like that then keep current state number in the orders’ table as well for each order. Every time when you insert new event update it. This way you get strange result when you print out all events of a certain order but you never find yourself in the position that current state is wrong.

Posted on

Photobucket stores plain passwords in its database?

I don’t know perhaps I’m way too naive but I would have thought that a site as popular as this one cares more about security. But apparently someone who was trying to retrieve their login information has typed in my username which results in two emails to my address both containing my current password. I hope they can remember their own username as well in the end :D.