Lectio is password protected

[jakupmichaelsen]

Do you have plans to update LecToCal following Lectio's move to password-protected schedules?

[Hanse00]

It's a great question.

I'm currently unsure if I should proceed to try to solve this problem.
The issue is, as Lectio has no API for me to use, the one way I can see to make this work, is to ask people for their Lectio login details, and pass that on into the script.

However I don't feel comfortable asking people to provide me with their login details.

[jakupmichaelsen]

Perhaps make it possible for users to save or pass the credentials as plain text?

[charlotdk]

Hi Hanse00. - and other python clever people.

I also have the problem with the password proteced Lectio. Since I work 2-3 places I am greatly depended on my calender and not having lectio in my Goggle calender (and thus on my phone) makes me weep every day!! o_o

I have/had the working version of a script, usually I open cmd as administrator and then run a line of program. I know absolutely nothing about python - but can open and read a script and "pseudo code".
So, if parsing our user and password through text from some source is to much work, perhaps they can be a part of the obligatory arguments to this line?

Or, perhaps a new "run" file can contain dummies, like %write your user here% and %write your password here% and then contain the old call, {mine is: lectocal.run (school_id) teacher (id)} somehow? Just if a brand new script file is easier to write for LecToCal master.
I think that even I, at my modest level of knowledge, with a "read me file" to help could edit the script with my own information and then make it run again.
I am motivated to try several times until it works!!! ^_^
However, editing the script to work with the new changes are simply more than I can imagine I could ever learn.
Can enyone help? With a sort of solution? :) :) :)
Or a brand new lovely LecToCal package? <3 <3

Regards,
Charlotte

[Hanse00]

Hey Charlotte and Jakup,

Thank you for your comments.

I want to make one thing perfectly clear for you, and anyone else who might bring this up:
The problem is not technical, but ethical.

You've both outlined possible strategies for LecToCal to collect people's Lectio credentials, and use them on their behalf. However no matter how we go about this, via a text file or by entering the details directly into the parameters of the script, this implies the script must have your Lectio credentials in memory at one time or another.

If I @Sobuno or I were unethical people, we could find ways to abuse this, and compile a list of your Lectio login details. This would allow us write nasty messages to other people, delete assignments, or otherwise abuse your access.

Whilst I appreciate you may trust me with this information, the fact of the matter is you shouldn't, and I wouldn't. Due to the design of Lectio there doesn't seem to be any alternative to this solution.

This is then the dilemma I am left with:

• Accept that LecToCal cannot work any more, due to the recent changes.
• Knowingly ask people for their Lectio credentials, perpetuating a dangerous practice for people to share their credentials with 3rd parties.

Currently I am leaning towards the first option, as much as I understand it wouldn't be great for any users of the software. Unless something drastically changes my mind, I don't think it would be morally defendable of me to do option 2.

[Johandersen]

Thanks for commenting on this
I don't quite follow this because the software is open source and everyone can read the code. So there is no way for You to secretly collect any data.
The user is responsible for their own privacy and security when running an open source script
Maybe it is not ideal to sore the login in plain text or in bash history but anyone should be sure to keep their system private anyway. And without api it's definitely the best option for me and the other users if I understand the comments right

[Hanse00]

the software is open source and everyone can read the code.

Whilst you're correct that the code is available to be read here, you have no guarantee that the package on pypi actually contains the code in the repository. I could easily inject some bad code before publishing a build.

Of course if you download the code and build it yourself, I couldn't do that. However I think it's safe to assume that the majority of users, do it the way that's easiest.

The user is responsible for their own privacy and security when running an open source script

I'm not sure if I agree with this. Ideally you should know what you're doing true, but as the publisher of this product, I believe it's ultimately my responsibility to ensure it's secure. As with any other digital or physical product, you may happen to know something about it, but the dealer is accountable for not selling you unsafe products.

[...] it's definitely the best option for me and the other users if I understand the comments right

You're correct in your understanding. As I see it there's a terrible solution, or no solution. There's no good solution here.

I'll have to think about it a bit more, before I can decide if I want to move forward with this.
As the code is open source, anyone else can of course make a fork and update it themselves if they'd like.

[charlotdk]

Hi Hanse00 -and other readers

I am sorry if I by this next comment show my lack of understandig but -why would the package be unsafe? I mean, I have python on my computer and I run the script on it here. As far as I know, i have downloaded the packages and they are also "here" -(I have tried reading them to see if I understand how the magic works..)
I get that "bad people" could do "bad things" by hiding stuf in the package, but then the users would spread the word, maybe I gues. But this would bring stuff to my computer, not transport data out?

What i dont get is, that if I edit my version of the script I run on my PC, to contain hard-coded my username and password, could it not be done in the same manner as my google information? I mean, the authentification makes a json file, this saves my user-password information on this pc, does it not?
This is -for me- much more "dangerous" than my Lectio information, that is just my job, google documents my entire life ;) ;)
Ok, maybe I dont know enough, but I do know that allready now I have been late to my other job 1 time, late for a class 1 time (and the teacher I asked to cover me also forgot, we dont have a working calender system or alert or whatever, no google, no outlook, no nothing just brains and papir.. And since I loose both during the day I always use a calender, so now I am lost) and they called and asked "where are you? why are you not with your students?" and I have missed my dentist appointment 3 times in a row, and making new ones with doctors, whatever, weeks in the future is just a mess.
I always end up choosing a monday in a week WITH lectures instead of without, the scripted transportation of Lectio Schedule was not the ideal solution, but it helped me alot every day. Why Macom or Lectio does not work with "export to calender" is a mystery to me.

So I hope that somehow the LecToCal can work again, and I guess I am willing to take the chance with my information.
Perphaps what should really be done was putting more pressure on Macom? Lectio is a really poor program.

Regards Charlotte

[chubby1968]

I've uploaded a modified version of the lectio.py here. It can be used to login with LecToCal. Use at your own risk.

[jensjacobt]

I made modified version where you enter a cookie (copied from a browser). This has two security advantages:

1. The cookie doesn't contain the users password.
2. When the session ends (e.g. when the user logs out) the cookie can no longer be used.

It has a few of obvious disadvantages:

1. You can't make a cron job (at least not easily).
2. There are additional steps: opening the browser, logging in, and copying the cookie.

I can share the code, if you would like.

Regards, Jens

[Johandersen]

Fantastic news! For me automatic sync with login stored in text is preferable, but nice that so many options are suddenly available

[Hanse00]

@jensjacobt do you have any idea how long it takes for the cookie to expire if you don't actively log out?

I think the most secure option here might be for the script to automatically open up the login page, if the cookie isn't present, let the user log in, and then grab the cookie to save together with the OAuth2 credentials. That way we can prevent the user providing the credentials directly to the script.

[Hanse00]

@charlotdk I want to address a few of your comments:

You mention your Google account credentials being "unsafe".
Google provides a mechanism named OAuth for this purpose. As you might have noticed the first time you use the program, you get directed to Google's website to log in, and give Lectocal permission to access your calendar. This means the token the script gets, doesn't contain your password, it only contains a "secret" which must be passed to Google, every time I want to update your calendar. I could for example not use this same secret, to open up your Gmail, Google Drive, or post on Google+ on your behalf.

The problem is that Macom doesn't provide any similar mechanism for Lectio. So it's all or nothing, as soon as I have your password, I can do anything.
This is further a problem because many people unfortunately use the same password for many services (Ideally you should use a Password manager like 1Password, KeePass, Dashlane, or similar), so chances are that if I collected people's Lectio passwords, I could also gain access to their Google account, their Facebook account, and maybe even more.

[...] I guess I am willing to take the chance with my information.

I need to drive home a point about this opinion, because I've heard it from multiple people.
Frankly it doesn't matter if you're willing to take the chance, I'm not.

If something did somehow go wrong, I could be held legally liable for any damages.
The whole point of having password protected systems, is about liability from an organizational perspective.
Because only you know your Lectio password, your school can hold you accountable for anything that happens on your account. The moment you share it with me, there's now ambiguity, because you could just claim "I didn't do it, it must have been that script".

I know the IT industry has taught users bad habits over the last 20 years, with IT support staff asking people their passwords, so they can look into an issue on your behalf. I work in that industry myself, and that's what has lead me to the very strong opinion that you should never ever under any circumstances share your password with anyone.

I'm sorry that that opinion is inconvenient, but sometimes you have to choose your battles, and I've decided I will not be a part of this terrible industry practice which needs to stop.

It looks like @jensjacobt might be onto a path which might allow the script to work again, without you needing to enter your password directly into it. If we can figure something out along those lines, I will happily work on making that happen, but I will not be a part of teaching people to indiscriminately sharing their passwords with 3rd parties.

Perphaps what should really be done was putting more pressure on Macom? Lectio is a really poor program.

I absolutely agree that Macom needs to give people access to their schedules in whatever way works for them, but it looks like they have close to a monopoly status in Denmark, so there's not much reason for them to listen.

You're more than free to contact them if you're interested, their details can be found at http://macom.dk/publish/da/lectio.htm

[charlotdk]

Hi Hanse00
Thank you for your reply to my comment, and also for the explanation of "how stuff works". I am sorry if my "take the chance" comment seemed like indifference, I am careful with my information, and the OAuth package uses the json file in a way so you do not get my information. This is what I mean with "here" ergo "on my computer and not going out in the data abyss". Python is also on my computer, and the script with my information would be here.
I had the idea that the Lectio login could be done in the same manner (you say it is not technically possible, Lectio is rather limited in function...). So it was not a "you can have my information - and I take the chance" but every time one uses a browser and type a login, or download stuff from the internet, you do take a risk with "bad people doing bad things". I could have some virus or worm reading my data, and the more software, auto-login, files saved with my password etc I use, the more "risky behavior" I show - or so I have come to understand.
And also, I agree with the bad habits people have with their IT support - and I never give away my login (but if someone has somehow sniffed it out, I wouldn't know).
People seemed supportive of the LecToCal package and so I tried it and it made my day easier. But, I am not software-savvy enough to understand what problems the new changes give, or "how risky" the "risky fix" is, compared to "how risky the original fix is", but I am happy to see that solutions are on the way, that does not set my password at risk (and, this password is only my password for Lectio ;) - no reuse. I try :) )

Yes, unfortunately Macom has a practically monopoly status, and this sadly means that thousands of people (all teachers, staff, and students) everyday must suffer this and other inconveniences. For me, working two part-time jobs it is complicated. I do regularly contact Macom and point out the lack of an actual calendar function, but the reply ranges from "this is a new complaint" to "not a priority right now" and, for some weird reason, some of the Lectio schedule appointments do show up in a calendar, at my school it is Outlook, only it shows up 3 times duplicated, making a week-overview impossible and the regular classes do not appear there.
Basically, it is a mess...!
Lectio makes me cry pretty much every day (some times in anger...).
And with all the problems and extra clicks and cumbersome file-handling etc we end up spending so much time on it - time that I could have spent teaching someone something useful.

Thank you all for your comments and help. I will stay tuned.
Regards
Charlotte