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 (schoolid) 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

[Hanse00]

Thanks everyone for your input.

I had a look over the Google Cloud Console, which has some built in metrics for the program's use of the Google Calendar API.

Over the last 30 days, calendar.calendarList.list has been called 5,461 times. This method is called exactly once during each run of the script, which gives us a pretty good idea of how much it's used.

That's significantly more than I would have expected.

With that information at hand, I think it's worthwhile trying to keep the system alive. It seems like a lot more people would notice if I didn't, than what I would have expected.

With that in mind however, it seems like keeping this system working might become somewhat of a battle against MaCom in the long run, and I'll have to make periodic updates to keep it working.

However for me to be able to dedicate significant time to this project, I will have to find a way for it to make sense financially. I'll have to think a bit about what I can do in that regard.

[soeren-b-c]

(Hi @Hanse00 . Sorry if you feel this reply is inappropriate for the thread. Feel free to delete if you think it crosses the line of good internet behaviour.)

@charlotdk (and others). I use (and administrate) another tool, build with Node.js. You can find it here: https://github.com/soeren-b-c/lectio-skema-til-.ics-kalender and it works right now (for me).

It opens up a webserver that you can query for your schedule, and it will give you an .ics file.

How you use that file afterwards is up to you, but you could upload that file manually to your Google Calendar. I personally have an automated setup, which is outlined in the documentation.

It is an option if you need it. If you can get LecToCal or another tool to work for you, that's cool too.

Cheers Søren

[jensjacobt]

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

The cookie takes a least 50 minutes to expire, if you don't load another page. However, the cookie is reset every night, so you can't have the script running automatically for more than one day.

I've made a version of the script that lets you login via command prompt (hidden password similar to ssh and so on) and saves the cookie to disk. This uses the flag --login. The script can then update the schedule for the rest of the day without user interaction (but via cronjob).

@Hanse00, let me know, if this has interest.

[Hanse00]

Thanks @jensjacobt that seems quite interesting. Is your script available on GitHub or elsewhere?

I see that there's a need to continue developing this tool for the time being, however as I am no longer an active participant of the Danish educational system, I don't have any lectio credentials of my own that I can test with. I will need to find someone to work with, who can help me actually test the functionality of the script, otherwise I am more or less coding blind.

[charlotdk]

Hello Hanse00 I am still struggling with not getting any of the fixes to work. So, if you need a way to test your new build of LecToCal - the old one actually worked and me and some of my colleagues used it, I would like to help. I cannot just give you my user-and-password however, but if we get a private contact somehow I could lent you my information for temperate use.

I have only "been in the system" for a short amount of time, and it has only been closed (password protected) for a few months, so I do not see a big problem with this. Though I do not do it lightly :)

The problems of not-having-a-calendar are much more clearly and disturbs me every day, so if you have or soon have a fix to test, I am your man (unisex).

Before all of this broke down I was trying to change the 4 weeks to something more like 8 or whatever, since I still try and work 2 jobs (it is not going well). But my python-skills are poor and some find all my questions annoying... GG .

!!!!! (sorry, I have made a new issue in what I hope is the proper place for such a thread) !!!! Also, if anyone has a fix that works or can tell me how to do the "chubby1968 commented on 27 Feb" fix (it runs for me now, that I use an ANSI version of Lectio.py but nothing appears in my calendar) I am still looking. The whole thing of replacing with a cookie etc to make it safer seems also as something useful to learn, but, since NOTHING appears in my calendar I am saving it for level 2 - after something that works...

Has anyone in here got the "new quick-n-dirty Lectio.py" to work for them? Is there a trick I simply do not understand? !!!!! (sorry, I have made a new issue in what I hope is the proper place for such a thread) !!!!

Best Charlot

[jensjacobt]

I have now put in a pull request with the updates I talked about. This uses some of the code from chubby1968 but it doesn't store the password. It is working from my command-line. My short comments are these:

Add backoff: To avoid exceptions from due to ?timeouts? from the Google Calendar API.

Add login with password: The new flag "--login" takes the username from Lectio. If this flag is set then the user is asked for his/her password in the typical command-line way.

Add cookie handling: Upon succesful login the cookie is save to file. The calendar can then be updated without the "--login" flag until the Lectio session expires. The "--keepalive" flag is designed to be run such that session does not expire. It sufficient to run the script with "--keepalive" every 50 minutes, however, the session will expire every night.

Edit: I haven't worked with Pipenv before. The Piplock.file isn't updated with the new packages that were used. Can you help me with that, Hanse00?