Articles

Object-orientated and functional paradigms

Posted by on May 3, 2012 in IT College, Opinions | 0 comments

Object-orientated and functional paradigms

I’ve been writing code for well over half a decade now… and I feel like the journey is just beginning. This article is a collection of subjective musings about object-orientated and functional paradigms, their advantages, disadvantages and use in real world software engineering, from the viewpoint of a [arguably young] software developer.
[It's also a hometask for I230]

Read More

Infosüsteemide eetikaprobleemid

Posted by on Feb 18, 2012 in IT College, Opinions | 0 comments

Eesti Infotehnoloogia Kolledži aine “Infosüsteemide analüüs ja projekteerimine” raames. Allpool esitatu on olemuselt pigem esseeistlik töö ning põhineb autori subjektiivsel arvamusel. Soovitav on lugeda tööd Google Docs keskkonnas.

Ülesande kirjeldus

Tuua kaks infosüsteemi arendusprojektide näidet, kus arendajad puutusid kokku erinevate eetiliste probleemidega
1. Lühidalt kirjeldada projekt
2. Iseloomustada eetiline probleem
3. Tuua välja huvitatud osapooled
4. Pakkuda välja võimalikud lahendused
5. Selgitada, miks tegemist on just eetilise probleemiga

Pakkuda välja 5 reeglit, kuidas käituda eetiliste probleemide puhul.

 

Projekt #1: Ehitusfirma kodulehe realiseerimine

Kirjeldus

Tarkvaraarendusega tegelevale firmale esitati tellimus ehitusfirma kodulehe ja -haldusliidese tarkvara loomiseks. Loodav koduleht kasutaks üht kujundust, mille sisuala vastavalt valitud lehele vaheldub. Lehti saab luua ja muuta haldusliidesest. Lisaks staatilistele lehtedele sisaldab koduleht ka dünaamilisi osi: mooduleid ning automaatselt genereeritud tekste (sisukokkuvõtted). Mooduliteks on näiteks tehtud tööde moodul, kuhu sisestatud andmete põhjal genereeritakse automaatselt külastajale nähtava lehe sisu või uudiste moodul, mida kuvatakse parempoolses kõrvaltulbas.

Probleem

Probleemi vaatleme tarkvaraarendaja seisukohast. Arendaja probleemiks on ressursihaldus. Projektil on piiratud eelarve ning aeg, kuid kliendile tuleks pakkuda parimat kvaliteeti ning realiseerida võimalikult palju kokkulepitud nõuetest. Kvaliteedi saavutamine tähendab muuhulgas ka süsteemi planeerimistegevusi, dokumenteerimist ja testimist.

  • Kas kujundada süsteem nii, et seda on tulevikus lihtne hooldada ja laiendada või teha “üle põlve”, arvestades praeguseid spetsiifilisi vajadusi (ning riskides tulevikuprobleemidega)?

  • Kas testida süstemaatiliste meetoditega ja põhjalikult teades, et sügava testimise vajadust on hiljem kliendile keeruline põhjendada ning see venitab eelarvet?

  • Kas jälgida standardeid või teha võimalikult kiiresti?

  • Kas pühendada aega ka teiste veebisirvijate toele või kasutada vaid enimlevinute viimaseid versioone?

Huvitatud osapooled

Osapool Huvi Tulem, huvi avaldumine
Arendaja Pakkuda kliendile parimat kvaliteeti, säilitada oma meelerahu ning reputatsioon. Projekti eelarve ja läbiviimiseks kuluv aeg kasvavad, klient võib olla rahulolematu või keelduda maksmast, minnes pakkuja juurde, kes pealtnäha sama tulemi odavamalt valmistab.
Projektijuht Kindlustada kodulehe valmimine eelarve ja tähtaja piires. Tagada kliendi rahulolu. Surve arendajale tekitab puudujäägid kvaliteedis ja ulatuses. Võimalus, et süsteemi hooldusfaasis avaldub kliendi rahulolematus.
Tarkvarafirma omanik Kindlustada projekti edukas lõpetamine ja kliendi maksevalmidus. Surveahel: Klient -> Omanik -> Projektijuht -> Arendaja
Klient Saada määratud eelarve ja ajakuluga kvaliteetne ja kokkulepitud tulemus. Kompromiss kõigi kolme osas: tavaliselt suurenevad eelarve ja tähtaeg, et tagada aktsepteeritav kvaliteet kõikide nõuete realiseerimine.
Veebilehe külastaja Saada hea kasutajakogemus. Leida soovitud info kiiresti.Nautida lehte visuaalselt. Vigade leidmisel negatiivne tagasiside kliendile, kliendi reputatsiooni langus külastaja silmis.
Veebilehe hooldaja (tarkvaraarendaja #2) Teha soovitud muutused süsteemis kiiresti. Teada, et olemasolev süsteem on töökindel ja testitud. Eelarve suurenemine, kui juba valmis süsteem ei ole tulevikuga arvestanud.
Veebilehe sisuhaldur (inimene, kes veebilehte infoga täidab) Suuta täita kõik nõutud tegevused kasutajasõbraliku haldusliidese kaudu. Puudujääkide ilmnemisel negatiivne tagasiside ülemusele, kaudselt ka tarkvarafirmale.

Lahendused

Probleemile pole 100% õiget lahendust, need piirangud on olemas igas projektis ning jäävad ka tulevikus kehtima. Kõige enam ilmnevad ressursiprobleemid klassikalise Waterfall ehk kosemeetodiga, kus kogu projekt on algusest planeeritud ning kasutatavad ressursid lukustatud.

Üheks võimalikuks alternatiiviks oleks agiilse metoodika kasutamine, kus soovid ja teostused tehakse iteratsioonidena. Siis on ootamatused ja muutused kergemini hallatavad ning kliendil on parem ettekujutus projekti seisust.

Agiilse metoodikaga (Scrum) projekti planeerimisel kasutatakse ka järgnevat meetodit: kliendil lastakse valida kolm olulist piirangut neljast (kvaliteet, ulatus, eelarve, raha) ning neljanda hindab arendustiim vastavalt esimese kolme määrangule. Seda  tehnikat kasutades ei lange kogu vastutus arendaja (projekti meeskonna) õlule.


(pilt: http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts#Sprint)

 

Eetikaprobleem?

Tegu on eetikaprobleemiga, mis langeb arendaja õlule, sest just arendaja teab kõige täpsemalt, mis koodi sees toimub. Realiseeritud süsteem võib kliendi ja juhatuse poolt vaadatuna küll ilus ja töötav olla, aga arendaja istub sel ajal häbitundega ja vaikides: koodis on turvaaugud, see on ehitatud standardeid ja metoodikaid järgimata, raskesti hooldatav, dokumenteerimata.

Julgemad arendajad räägivad sel teemal projektijuhi, juhatuse ning isegi kliendiga, küsides juurde aega ning ressursse: eesmärk on neil kõigil ju ühine: kliendile võimalikult kvaliteetse toote pakkumine. Tihti selline läbirääkimine aga ebaõnnestub, sest vajadust ei suudeta mittetehnilisele kliendile piisavalt kästi kommunikeerida või pole klient lihtsalt valmis parema lahenduse eest rohkem maksma.

Olgu olukord milline tahes, tulem jääb siiski liigagi tihti samaks: valmistatakse süsteem, mille selle ehitanud arendaja heameelega prügikasti saadaks.

Projekt #2:  Catering firma tööde infosüsteem

Kirjeldus

Tarkvarafirma on loonud oma kliendile (kelleks on suur ja mainekas catering firma) infosüsteemi kliendi infohalduse automatiseerimiseks. Süsteem on laiaulatuslik, võimaldades muuhulgas…

  • Klientide ja kliendiandmete haldamist

  • Ühekordsete ja korduvate tööde sisestust ja haldust

  • Arvete koostamist tehtud tööde põhjal perioodiks (üks kuu)

  • Firma finantsaruannete koostamist

  • Hallatavate objektide (hooned, asutused) haldust

  • Töötajate ja palgagraafikute haldust

Nagu näha, on tegemist  üsnagi andmemahuka ja keerulise süsteemiga. Süsteem sisaldab kliendi poolt aastate jooksul sisestatud andmeid, logisid, üleslaaditud faile ning firmasisest kirjavahetust.

Probleem

Olukorda illustreerib hästi analoogia teise, hiljuti meedias tähelepanu saanud analoogse probleemiga. Nimelt esitas “Europe vs Facebook” grupp Iiri andmekaitseorganile nimekirja kaebustega sotsiaalvõrgustik “Facebook” vastu. Kaebused olid seotud suurkorporatsiooni andmekasutusega, nimelt süüdistati firmat klientide andmete ebaeetilises kogumises ja kasutamises.

Olukord on paradoksiaalne. On mõistetav, et iga andmetel põhinev süsteem (Facebook, Gmail, pangad, catering firma infosüsteem) peab oma funktsionaalsuse täitmiseks säilitama tundlikke andmeid. Samas ei soovi andmete omanikud (objektid, füüsilised- ja juriidilised isikud) tihti nende andmete (õigustamata) eksisteerimist kolmandate osapoolte käes, põhjendades seda õigustatud väitega, et selliseid andmeid saab kuritarvitada andmete valdaja või muu juurdepääsuga isiku omakasu huvides.

Catering firma infosüsteemist rääkides on sellisteks isikuteks süsteemis haldaja rolli omavad töötajad ning tarkvarafirma arendajad, kes andmebaasile ja süsteemile vahetut ligipääsu omavad. Siit ka eetikaprobleem: kas catering firma peaks muretsema võimu üle, mida arendajad omavad ning vastupidi; kas arendajad  peaksid võitlema süümepiinadega hooldustöid sooritades?

Huvitatud osapooled

Osapool Huvi Tulem, huvi avaldumine
Catering firma töötaja Säilitada oma andmete privaatsus firmaväliste isikute suhtes: tehtud tööde info, palgagraafik. Garantii küsimine info kaitsmise kohta tarkvarafirmalt: NDO (non-disclosure-agreement), lepingusätted.
Infosüsteemi haldaja Tagada süsteemi andmete õigsus, kontrollida töötajate tegevusi. Töötajate tegevuse auditeerimine, vastutamine andmete  ja tegevuse õigsuse kohta. Surve tarkvarafirmale programmi hooldus- ja monitoorimisvõimaluste teostamiseks.
Tarkvarafirma arendaja Tagada süsteemi toimimine hooldustööde ja edasiarenduste kaudu kasutades selleks andmeid olemasoleva süsteemi toimimise kohta. Infosüsteemi andmete kasutamine testide koostamiseks. Vastutus mõlema firma ees andmete privaatsuse ja rikkumatuse tagamiseks.
Tarkvarafirma juht Tagada süsteemi toimimine, vältida kliendi pretensioone privaatsuse osas. Kindlustamine, et süsteem andmeid ei hävitaks ega lekitaks. Läbirääkimised kliendiga arendaja soovitatud hooldustööde tasustamiseks.
Catering firma klient Saada kvaliteetset teenust, tagada catering firmaga vahetatud info privaatsus kolmandate isikute suhtes. Catering firma usaldamine oma andmetega. Väärteo kahtlusel pretensioonide esitamine vastava(te)le seadusorganile auditi korraldamiseks.
Andmekaitseagentuur Tagada kehtivate seaduste täitmine catering- ja tarkvarafirma poolt. Pretensioonide töötlemine catering- ja tarkvarafirma vastu. Audit infosüsteemi tööle ja käideldavate andmete kasutusse.

 

 

Lahendus

Tegemist on eetikaprobleemiga, mille tuvastamiseks on raske diskreetseid ja ühetimõistetavaid piiranguid seada. Iga infosüsteemi valdajal lasub moraalne ja eetiline vastutus oma võimu mitte kuritarvitada.

“With great power there must also come — great responsibility.”

(suure võimuga käib kaasas suur vastutus)

- Amazing Fantasy #15 (2)


Kuritarvitamise piir sõltub aga vaatepunktist ja eeldustest.

Info valdajale antakse andmed usalduse alusel: panku usaldatakse konto saldo saladuses hoidma, sotsiaalvõrgustikke isikuandmete puutumatusega. Järelikult on need firmad teinud midagi, mille põhjal on meil alust arvata, et tegu on maineka ja usaldusväärse asutusega. Selle eelduse tekitamiseks peavad asutuse töötajad lähtuma teatud kehtestatud või ühiskonna poolt omaks võetud eetikastandarditest, nagu näiteks Arvutustehnika Eetika Instituudi poolt välja antud kümme käsku (1).

Võimu kuritarvitamise ennetamiseks on riiklikul tasandil rakendatud negatiivse tagasiside süsteem: kuritarvitad informatsiooni (näiteks pakub süsteemi arendaja catering firma konkurendile andmeid firma finantsolukorra kohta), lähed vangi. Sellise lähenemise probleemiks on asjaolu, et karistuse rakendamiseks peab rikkumine olema avastatud. Paremini töötab süsteem, kus positiivsete julgustustega – kasvatus, koolitused – julgustatakse inimesi õigesti käituma.

Eetikaprobleem?


Andmete kuritarvitamine on internetiajastul ja informatsiooni leviku tõttu aina rohkem tähelepanu saav probleem. Sotsiaalvõrgustike teke on kodanikkonda probleemist informeerinud ning hiljutised seaduseelnõud – SOPA, PIPA, ACTA – on valitsuse vastus probleemiga tegelemiseks.

Tarkvaraarendaja igapäevaelus tuleb tihti ette olukordi, kus töötaja peab kasutama kliendi konfidentsiaalseid andmeid mingi toimingu soovitamiseks. Neil puhkudel tuleb võidelda oma sisemise minaga ning selgitada iseendale, et antud juhul on andmete kasutamine õigustatud ja vajalik. Selle lahingu kaotamisel tuleks sügavamalt üle vaadata andmete kasutamise põhjused. Selline käitumine tagab kliendi usalduse, soodustab ärisuhte jätkumist ning väldib probleeme andmekaitseorganitega.

Käitumisjuhised tarkvaraarendajale eetiliste probleemidega hakkama saamiseks

Järgnevalt on toodud viis juhist tarkvaraarendajale eetiliste dilemmade lahendamiseks.
  • Kui seisad ristteel – küsi nõu.Ülemuselt. Projektijuhilt. Kolleegilt.
  • Säilita kliendi usaldus – ära kuritarvita konfidentsiaalseid andmeid
  • Lähtu otsuste tegemisel ühiskonna tavadest ja ajaloost.
  • Kasuta kõiki võimalikke meetmeid oma vigadest tingitud kahju minimeerimiseks.
  • Informeeri ülemusi ja klienti nende poolt pakutud valikute tagajärgedest.

Viited

  1. http://computerethicsinstitute.org/publications/tencommandments.html
  2. http://en.wikipedia.org/wiki/Uncle_Ben#cite_note-10
  3. http://beta.wikiversity.org/wiki/IT_eetilised,_sotsiaalsed_ja_professionaalsed_aspektid/Tsensuur,_privaatsus_ja_Internet
Read More

SQroot.eu is participating in SOPA strike

Posted by on Jan 17, 2012 in Opinions | 0 comments

SQroot.eu blog will be closed to all visitors for 24h on Wednesday, January 18. The blackout is part of several hundred similar protests, including some internet giants like Wikipedia and Reddit.

The protests aim to draw attention to the SOPA and PIPA legalization acts that would seriously alter the Internet as we know it today.

Visitors arriving to the site will be redirected to an informational page about SOPA.

Read more:

…or watch this informational video:

 

Read More

Dear FB, My Data, Please!

Posted by on Nov 30, 2011 in Featured, Opinions | 0 comments


I’ve been following Europe Verses Facebook for quite some time now and very much approve of the notion. I requested a copy of my data about a month ago and received a dry reply today. Not surprisingly, I was directed to use the profile download tool to get a copy of “all the data that we believe necessary to comply with the requirements of data protection law“.

Like hell. I’m more interested on what goes on behind the scenes. Luckily, there’s a dumbed-down version on how to persuade Facebook to do peoples bidding.

Now to the month long wait, again…

You can access your data immediately any time, free of charge. In this download, we’ve included all the data that we believe necessary to comply with the requirements of data protection law. Please note that this tool provides you with data that is currently held in your profile (timeline).

Please note that we are currently undergoing an audit by our European data protection regulator, the Irish Data Protection Commission.  This includes an examination of the categories of data that should be provided in response to a subject access request. This may result in changes to the download tool in the future.

- Email from Facebook to Ando Roots

Note: Facebook has made it more and more difficult to send an access request since the beginning of your campaign. The legal deadline of 40 days is currently ignored. Users get rerouted to a “download tool” that only allows to get a copy your own profile (about 22 data categories) but does not provide you the data Facebook is collecting and storing in the background (about 35 data categories).

- From http://europe-v-facebook.org/EN/Get_your_Data_/get_your_data_.html

Update: I didn’t hear back from Facebook after the legal deadline so I wrote to them on paper. A bit more difficult to ignore now. P.S! You owe me 1.09 €.

Update (26. Jan 2012) I just received another email from Facebook about my data request(s)… which, by the way, doesn’t specify if it’s a response to the online form (my 2nd attempt) or the above handwritten letter. The email says, in the nicest of terms, that I should find all the information I want by using their online data download tool.
/–/
Please note that as this reply contains all the information necessary for you to exercise your subject access rights we will not enter into further correspondence about your specific data through this email address.
/–/
We’ve built a convenient self-service tool to offer people who use Facebook the opportunity to access the personal data we hold about them in accordance with the provisions of EU Directive 95/46/EC.
/–/
 In this download, we’ve included all the data that we believe necessary to comply with the requirements of data protection law.
- Annotated excerpts from the email
However, from europe-v-facebook.org:
Facebook is sending out e-mails in which they claim that you can download all data via the “account settings” page on their web page. In fact you only get a minimal amount of data when downloading this file (about 22 data categories instead of more than 76!)
I’ll have to wait some more until 40 days from my third data request (1: online form, 2: e-mail to datarequests@facebook.com, 3: handwritten letter) pass, then I can (and most likely will) file a complaint to the Irish DPC.
Update Received another letter from Facebook, by electronic mail, basically thanking me for my interest and directing me to use their download data tool… again. I’m not going to waste the effort on filing a complaint on them, but I am terribly disappointed.
From their own policies:
“You will delete all data you receive from us concerning a user if the user asks you to do so, and will provide an easily accessible mechanism for users to make such a request.”
https://developers.facebook.com/policy/, section II, paragraph 12
As far as I know, the first is impossible with their own service and the second – really darn hard as the above saga proved. Way to set an example…
Read More

Opinions: Be a Developer… Part III

Posted by on Nov 14, 2011 in Articles, Opinions | 0 comments

?This is a continuation of the previous posts, “Opinions: Be a Developer, Not a Programmer Part I” and ”Opinions: Be a Developer, Not a Programmer Part II“.
 

Ando Roots

Just a picking note to begin with: WordPress is more of a CMS than a pure framework…but never mind that. I wholeheartedly agree with you on the point of Kohana. It’s the fastest and most comfortable to work with PHP framework I’ve used, to date.

Indeed – before writing your first class or function, a developer should know the system he’s building. That’s a fact I’ve come to realize since I started working as a programmer. I used to begin with an idea and then just see where it goes, often tearing down an hours worth of progress. College and the real world taught me to do some initial planning (hey, at least I’m trying), but it’s still difficult to foresee the possible problems in the future. I guess it comes with experience.

Much of the initial planning is usually done by the project manager: collecting client requirements, making technical decisions (if qualified) etc. Still, modelling the database, the system and dreaming up the architecture is the job of a developer or an architect.

I still strongly object to the idea of labelling writing code as a mechanical process. The job of a System Architect is undeniably creative, but so is writing code or even mere functions with fixed signatures. There are many similarities with Mathematics, but even in Math one has to have certain creativity to see the possible paths to the solution.

When speaking of a typical end user (that’s another topic entirely), it’s true that he or she doesn’t really care about how the functions are written nor whether the product is analog or digital… as long as it fills it’s intended role. However, it’s wrong to say that the customer doesn’t benefit from a well-written codebase. Notice, I’m using the phrase well-written instead of beautiful. A painting is beautiful, the code can look like that with proper spacing and indention (and it should), but the characters and comments are what count. A documented, structurally solid and thought trough codebase makes later development and/or maintenance cost effective and ultimately, saves the customer money. If the company has a contract that says they’ll fix any and all bugs for free and the codebase is unmaintainable or undocumented, the cost of maintenance skyrockets.

I’m ashamed to admit it, but by your definition, I’m a programmer. I get an assignment and start to work on it, keeping in mind in-code documentation, a solid design and TDD. Sometimes I screw up (again, the inexperience) and have to start a particular piece of functionality using a different approach (and that’s only natural). I do think about usability, but the priority is to get the system up and running…and when that happens, the next project flies in. Not to mention the lack of feedback so I’d know how to improve the system from the user’s point of view.

You’re right in that I haven’t done any Agile development before. Nevertheless, I’d like to visit conventions like Tampere goes Agile and find out exactly what’s true. I for one don’t believe that Agile consumes huge loads of money for bureaucracy. The biggest investment on the client’s part is to iron out the specifics of the application with the help of the team and that’s only for their own benefit because if they don’t know what it is they want, they usually don’t get it. With that point, I’d like to copy the Agile Manifest from http://agilemanifesto.org/.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

We (you and I) build different systems. I work on a small company and know the possible expansion opportunities for my applications are virtually nonexistent since they are for internal, specific usage, not for a public service like Twitter. Therefore, frameworks always win in my case (I don’t want to reinvent strlen only to see if I could squeeze an extra millisecond out of it). If my system indeed needed to respond to thousands of queries per second, I’d ditch everything I could… but at the moment, it’s not a problem: the client’s company hires 100 new people, we increase the memory of the VPS by another GB. Different tools for different situations.

I believe most of us collect code snippets, samples and libraries like photographers: always ready with a camera. They’re extremely useful… but they don’t make the man. If your external HDD is stolen, you have to continue as normal. It’s the knowledge, experience and the ability to reason and envision what makes a worthy developer.

This concludes this miniseries of discussions. You’re welcome to further the discussion by leaving a comment down below.
Read More

Time and Cost in Favor Of Security

Posted by on Sep 26, 2011 in Articles, Opinions | 0 comments

Beginners dilemma: do it properly and actually learn something new or do it so it gets done fast. Never mind the flexibility, security and the feelings of future developers as long as the task at hand gets done with minimal time consumption and makes one look like a pro, for the moment.

That kind of attitude reminds me a mix of The Office and The Simpsons. Yes – you can hack together something that barely manages to fulfill the current requirements… but then someone exploits the broken system or it collapses because a change in the environment or another developer has to do it over again, maybe from his own spare time because the business side can’t justify the time spent on refactoring a kind-of working system.

I’m in full agreement that we (the developers) can’t follow the golden rules all the time in the real world and compromises must be made to lower the costs… and then I wonder what the clients would say if the company told them point-blank from where the money is/was saved. The fact that the developers think the website/app will never be under any sort of attack, trust the user to input the right kind of data or guard their cookies is naive.

A situation like that is even more passionate when the team is split: one of the developers believes and is willing to do extra work to have some confidence in his creation, the other just does like it’s always been done.

A Real-world Example

Imagine now that you had to set up a WYSIWYG editor with file upload capability – like CKEditor. CKEditor has 2 crucial parts for the server-side. One is the config file, the other the actual (PHP) uploader script. Below is a section of the config.php file.

/**
 * This function must check the user session to be sure that he/she is
 * authorized to upload and access files in the File Browser.
 *
 * @return boolean
 */
function CheckAuthentication()
{
    // WARNING : DO NOT simply return "true". By doing so, you are allowing
    // "anyone" to upload and list the files in your server. You must implement
    // some kind of session validation here. Even something very simple as...

    // return isset($_SESSION['IsAuthorized']) && $_SESSION['IsAuthorized'];

    // ... where $_SESSION['IsAuthorized'] is set to "true" as soon as the
    // user logs in your system. To be able to use session variables don't
    // forget to add session_start() at the top of this file.

    return false;

}

As you can see, CKEdit doesn’t really do anything until true is returned from the CheckAuthentication() function. It’s really tempting to do just that and skip the whole auth-thing to win those crucial minutes. The red (figuratively) warnings above don’t really mean anything because surely, who’d ever want to attack our site OR who’d ever think to exploit the file upload script? We have one login page in front of the uploading script anyway.

Yeah. So what really happens is that the user doesn’t notice anything unless (s)he has some technical knowledge and knows what to look for: an unprotected HTML page that accepts POST data. You’ve solved the current situation and don’t want to go back to deal with the problem. The customer is (wrongly) happy and you get paid.

You should never neglect the most basic security to win time – not on anything that eventually ends up in production. The problem above would be solved by including the framework/code that manages the main site and calling the auth check function. On Kohana 3 it would look like this:

define('SUPPRESS_REQUEST', TRUE);
require('../../index.php');
return Auth::instance()->logged_in();

Done! Problem solved. Did it really take that long? Assuming you knew something about Kohana and it’s modules.

If no-one specifically forbids you from thinking about security, do think about it. If you’re not allowed to write code you’re confident in, tell the managers they get what they pay for or find a new job.

Read More