gijstimmers / kotnetcli Goto Github PK

Please write a small info dialog to inform the user that he's not connected to the KU Leuven network.

Guest mode should be combinable with dialog for example This now auto starts curses:

if argumenten.guest_mode:
        ## werkt alleen met login op het moment
        print "ik wil me anders voordoen dan ik ben"
        cr = Credentials()
        gebruikersnaam, wachtwoord = cr.guest()
        co = communicator.CursesCommunicator()
        main(co, gebruikersnaam, wachtwoord)

Moreover, the credentials querying should also be passed to the communicaotor? This way the dialog communicator could ask the credentials via dialogs...

see 1a11d48.

$ python
import communicator
co = communicator.LoginColoramaCommunicator()
co.eventPingFailure()
## no output
exit()

If we implement this, Travis would be able to compile for us.

For Linux users, we should have a man page with all the info from the readme, wiki and --help flag in a readable and coherent form; (note: all info from the man page should also be available on the wiki, e.g. through a text dump of the man page)

It should come with an installation script (Makefile or so) that installs kotnetcli under /usr/local/bin and the man page under /usr/local/share/man/man1

The Makefile and/or dialog-based installer shell script of the jsh shell could be a good place to start

Marking this for release 3.0.0 'Cape Cod' ?

See this image:

This makes --force-login useless.

These modes currently don't work on Mac OS X:

• Dialog

Traceback (most recent call last):
  File "./kotnetcli.py", line 220, in <module>
    aanstuurderObvArgumenten(argumentenParser())
  File "./kotnetcli.py", line 184, in aanstuurderObvArgumenten
    co = communicator.DialogCommunicator()
  File "/Volumes/MacintoshHD/Users/wouterfranken/Development/kotnetcliFork/kotnetcli/communicator.py", line 111, in __init__
    self.d = Dialog(dialog="dialog")
  File "/usr/local/lib/python2.7/site-packages/dialog.py", line 1346, in __init__
    self._dialog_prg = _path_to_executable(dialog)
  File "/usr/local/lib/python2.7/site-packages/dialog.py", line 485, in _path_to_executable
    "can't find the executable for the dialog-like "
dialog.ExecutableNotFound

• Bubble

Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
Traceback (most recent call last):
  File "./kotnetcli.py", line 220, in <module>
    aanstuurderObvArgumenten(argumentenParser())
  File "./kotnetcli.py", line 191, in aanstuurderObvArgumenten
    co = communicator.BubbleCommunicator()
  File "/Volumes/MacintoshHD/Users/wouterfranken/Development/kotnetcliFork/kotnetcli/communicator.py", line 94, in __init__
    notify2.init("kotnetcli")
  File "/usr/local/lib/python2.7/site-packages/notify2.py", line 93, in init
    bus = dbus.SessionBus(mainloop=mainloop)
  File "/usr/local/lib/python2.7/site-packages/dbus/_dbus.py", line 211, in __new__
    mainloop=mainloop)
  File "/usr/local/lib/python2.7/site-packages/dbus/_dbus.py", line 100, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/local/lib/python2.7/site-packages/dbus/bus.py", line 122, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoMemory: Not enough memory

The kotnet login can run on a Fedora system with the folowing instructions:

sudo yum update
sudo yum install git python-colorama.noarch python-keyring.noarch python-mechanize.noarch

for using dialog the following package is needed:

sudo yum install python-dialog.noarch

i didn't find notify2

We moeten even overleggen over Kotnetforceer(). Kijk even naar 512ae35.

Kotnetforceer() heeft veel methodes gemeenschappelijk met Kotnetlogin() en Kotnetlogout(). We willen die niet opnieuw schrijven, dus laten we Kotnetforceer() deze methodes overerven:

class Kotnetforceer(Kotnetlogin, Kotnetlogout):
...

Het probleem is dat zowel Kotnetlogin() als Kotnetlogout() een methode resultaten() bevatten, welke ook beide andere code bevatten.

Mijn voorstel is om resultaten() van naam te veranderen in beide klassen, zodat het voor Kotnetforceer() duidelijk is, welke resultaten() opgevraagd worden:

class Kotnetforceer(Kotnetlogin, Kotnetlogout):
    def go(self):
        ## IP van uit te loggen apparaat opzoeken
        self.netlogin()
        self.kuleuven()
        self.gegevensinvoeren()
        self.gegevensopsturen()
        self.oudipophalen()
        ## Uitloggen
        self.formulieraanmaken()
        self.formulieropsturen()
        self.logoutresultaten() ## dit bedoel ik
        self.netlogin()
        self.kuleuven()
        self.gegevensinvoeren()
        self.gegevensopsturen()
        self.loginresultaten() ## dit bedoel ik

Een alternatief wat volgens mij ook werkt, is het expliciet oproepen van deze methodes, zonder de naam te veranderen:

class Kotnetforceer(Kotnetlogin, Kotnetlogout):
    def go():
        ## IP van uit te loggen apparaat opzoeken
        self.netlogin()
        self.kuleuven()
        self.gegevensinvoeren()
        self.gegevensopsturen()
        self.oudipophalen()
        ## Uitloggen
        self.formulieraanmaken()
        self.formulieropsturen()
        Kotnetlogout.resultaten() ## dit bedoel ik
        self.netlogin()
        self.kuleuven()
        self.gegevensinvoeren()
        self.gegevensopsturen()
        Kotnetlogin.resultaten() ## dit bedoel ik

Overigens ben ik zeker voorstander van een andere, properdere oplossing. Misschien iets met gedeelde methodes in SuperWorker(), bijvoorbeeld.

./kotnetcli.py --li <TAB>
./kotnetcli.py --licence

This should be done using the argcomplete library.

I agree with the proposed roadmap Good plan 👍

Would like propose some enhancements however:

kotnetcli 2.0

goal: a pluggable, cohesive, trustworthy standalone application -- Trusty Tahr ;-)

roadmap enhancements:

feature freeze: all new feature requests (new cli/gui/command line options; login actions; communicators; ...) should be incorporated into the road map for post 2.0 release. All open issues should be labeled according to the roadmap.

• Overal software design as a set of cohesive communicating modules, as discussed here and here should be completed.
• Lazy importing: running kotnetcli withouth all dependencies should work nice and fine when the not-installed-dependencies aren't used (e.g. dialog, curses, keyring, ...)
• Fail gracefully: exit with appropriate exit code and communicate the reason of failure through the communicator
• a fully working dummy-mode stable TravisCI testsuit

kotnetcli 3.0

goal: a smooth application, nicely integrated in the operating system -- Precise Pangolin ;-)

roadmap enhancements:

• Fully documented software design
• Explore ideas for alternative front-ends:
  • Android app
  • Gnome 3 / unity application indicator (http://blog.fpmurphy.com/2011/04/gnome-3-shell-extensions.html)
  • proof-of-concept dialog gui?
• Auto starting kotnetcli:
  • at boot time: robust way of telling whether or not on kotnet network
  • at network changing time: hooking up on ethernet plugin event? Wifi network change?
• Installers for various OSs:
  • AUR, deb file, windows installer, dialog based installer?
  • install to /usr/local/bin
  • auto install small man page?
• self containing builds for a variety of operating systems
• Config file ~/.kotnetcli with user default options?

Of course @GijsTimmers decides on the roadmap, so consider this as a proposal to incorporate the software design in the roadmap. Just a personal view / things I will be working on

Comments / Impressions / Ideas?

When netlogin.kuleuven.be server is not responding, it means the user is not on a KotNet network and therefore kotnetcli should exit gracefully with an exit code and information message (if not --quiet) to inform the user

A --logout flag would come in handy sometimes too (for testing stuff etc)

Running on Arch yields an index out of bound exception in the "tegoeden" code. The "zoekresultaten" array is empty:

Traceback (most recent call last):
  File "./kotnetcli.py", line 184, in <module>
    curses.wrapper(main)        ## Zorgt er voor dat curses netjes opstart en afsluit.
  File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
    return func(stdscr, *args, **kwds)
  File "./kotnetcli.py", line 181, in main
    kl.tegoeden()
  File "./kotnetcli.py", line 136, in tegoeden
    self.downloadpercentage = int(zoekresultaten[0].strip("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ%()<>br/"))
IndexError: list index out of range

Moreover the login fails on my system. When I put a sleep before the "tegoeden" code, it displays "OK" for the "gegevens uploaden step", but I am not logged on however.

Any ideas to fix this?

When an Arch user boots his computer, systemd services are executed. It would be nice to create one for kotnetcli, for a seamless Kotnet login. An Arch user should run:

sudo systemd enable kotnetcli.service

to enable this startup script.

Ubuntu will be moving to systemd as well, so the core developers won't put effort in creating upstart scripts. That doesn't mean we don't allow these scripts; just open up a pull request if you've created one yourself and we'll gladly merge it.

Things to keep in mind:

• Availability of libraries?
• We need to write a script to start up a VirtualBox, compile, put the .exe somewhere and close. This is possible.
• We would need a fancy icon, because PyInstaller's default isn't very appealing.

kotnetcli -o works fine when it is run on a computer who is logged in.
BUT when I run it on another machine who wants to be online then the next error appears

$ ./kotnetcli -o
ik haal de credentials uit de keyring
ik wil vrolijke kleuren
ik wil uitloggen
Netlogin openen....... [ OK ]
Gegevens invoeren..... [ OK ]
Gegevens opsturen..... [ OK ]
$ ./kotnetcli
ik haal de credentials uit de keyring
ik wil vrolijke kleuren
ik wil inloggen
Netlogin openen....... [ OK ]
KU Leuven kiezen...... [ OK ]
Gegevens invoeren..... [ OK ]
Gegevens opsturen..... [ OK ]
Traceback (most recent call last):
  File "/kotnetcli/kotnetcli.py", line 220, in <module>
    aanstuurderObvArgumenten(argumentenParser())
  File "/kotnetcli/kotnetcli.py", line 206, in aanstuurderObvArgumenten
    main(co, gebruikersnaam, wachtwoord, actie="inloggen")
  File "/kotnetcli/kotnetcli.py", line 46, in main
    kl.tegoeden()
  File "/kotnetcli/worker.py", line 90, in tegoeden
    self.downloadpercentage = int(zoekresultaten[0]\
IndexError: list index out of range

This would enable Windows to show both --plaintext and --colortext

Instead of the time.sleep(2) hack at the end to display the final status to the user, the script should re-print the final status on stdout after exiting curses. This can easily be accomplished with color escape codes and print statements: proof-of-concept :

(...)
curses.wrapper(main)        ## Zorgt er voor dat curses netjes opstart en afsluit.
print "\033[93m" + "hello world" + "\033[0m"

This way the output would simply be printed to terminal and users can see it above their current prompt:

The state should then be saved in the KotnetCLI object so it can be printed in the end. Of course we should't hard-code the color codes, but use final variables instead

--quiet flag should disable outputting progress and disable to 2 seconds sleep at the end (which is only there to allow the user to view the output). The script should then return a value >=0 on success, else a value < 0

This way adding kotnetcli --quiet to your startup applications etc will be neater

You should check whether adding:

import locale
locale.setlocale(locale.LC_ALL, '')

to the start of the program, changes the dialog messages to your default locale language (dutch)?

See eg http://pythondialog.sourceforge.net/#example

BeautifulSoup is better at parsing than the low-level re. It will also clean up the dirty parts in kotnetcli.py a bit.

Currently, the user just gets a dialog for the keyring. He may not know what password should be entered.

Debug stuff like ik wil bellen blazen should be elegantly logged using the python logging module.

We will work on this when kotnetcli 2.0.0 is released.

When you end kotnetcli with an exception, your terminal gets messy. We can avoid that by using curses.wrapper(YourCursesMethod()), but that's not so easy here.

Another way to do it would be to to write a scherm.terminate() method and put that in each exception catch. That's easy, but dirty.

Proposed languages:

• nl_NL
• nl_PJ (Pjotr-mode)
• en_GB
• de_DE
• fr_FR
• es_ES

Problems with the Communicator pattern

I think the switch to the communicator pattern has been one of the key moves in the kotnetcli project (i.a. discussed in #13). I strongly belief it is the good way to continue on. It nicely decouples core from visualisation concerns, allowing a pluggable visualisation system for everyones needs. It also keeps the code clean, allowing the programmer to focus on his task: the UNIX philosophy - do one thing and do it good.

Currently the pattern merely encapsulates all the visualisation calls. Initiating it can still be messy somehow. As we are porting kotnetcli on various platforms now however, time has come to enhance the pattern once more.

As discussed in various issues already (#48 #43), the current communicator implementations aren't portable / cross platform. This creates a dependency hell and makes keeping everything stable and up-to-date a hassle... :-/

Tackle the problem, not its symptoms

I belief this problem is not due to the communicator pattern an sich though: we shouldn't solve the problem by tackling its symptoms. That is to say: the real problem here is that specific Communicator instantiations currently aren't portable. The CursesCommunicator or DialogCommunicator for example happen to be to worst: i.e. the 'symptoms'. The problem itself is that the current code somehow expects a client to use all of the communicators (by importing them all) which then are instantiated according to the command-line flags passed.

What we should really fix therefore is the portability of communicators, the core of the problem.

Requirements for a solution

In my opinion, a good portable solution to this problem should have the following characteristics:

• crash locally: The code should 'delay' crashing to make sure it only crashes when needed. I.e. the code shouldn't crash for a communicator that you don't use (e.g. if you don't have dialog installed, but you don't use the DialogCommunicator there should absolutely be no problem)
• fail-gracefully: let it crash, but in a controlled way: always leave the system in a desirec state. Clean thing up nicely and show an instructive error message to the user. (e.g. the cursesCommunicator and ColoramaCommunicator have things to do for reinitializing the screen...)
• encapsulation of platform-specific code: most parts should be as platform-neutral as possible, but platform-specific code is not necessarily a problem (different platform ask for different methods). Platform specific code should clearly be encapsulated though, as opposed to having if (os ==) checks wandering everywhere in the code. Platform-specific code should be cleanly separated from platform-independent code.
• pluggable: extending the system with yet-another-communicator should be easy, straightforward and clean

Vers une architecture logicielle

I'll quickly sketch a possible outline for a solution here:

• inheritance: we should continue further dividing communicators into a class hierarchy. Common platform-independent code should be abstracted in superclasses and platform dependent specific code should be in a proper sub-class. See the encapsulation of platform-specific code and pluggable criteria above.
• Fail gracefully using exitFailure(msg) and exitSucces(): The non-communicator code should always call a function like co.exitFailure(msg) when it catches an exception and wants to exit the system. The communicator can then leave its internal state as desired and if needed, communicate an error message to the end-user. See the fail-gracefully criterion above. Symmetrically, we'll need a function like exitSucces() that also cleans up internal state and -if needed- communicates success to the end-user. Things like #47 are then trivial BTW.
• import dependencies on init(): We should also fix the import statements in a cleaner way: only import when actually used. I.e. import dialog only in DialogCommunicator.init() and colorama only in ColoramaCommunicator.init() etc. See the crash locally criteria above. More specifically, a user should be able to run kotnetcli without first installing colorama and/or dialog etc., be it in 'simple' plaintext mode then.
• crash platform-independent: the system should 'crash' gracefully, in the same way for a mac user who doesn't (and cannot) have dialog installed and a Linux user who just happens not to have the utility installed. This can be done by importing dependencies on init(), as decribed above, and subsequently catch an importexception and exitFailure();
• independance of command line arguments: parsing of command line arguments happens outside the scope of communicators, so they shouldn't rely on it in any way. More specifically, calling a communicator that should not / can not work on a certain platform (eg dialog on mac os x or mac-specific bubbles on linux) should not crash uncontrolled. See the fail-gracefully criterion above. The communicator should simply show a nice informative error message and exit. Thing like having a custom Argumentenparser() per OS, as discussed in issue #43 can surely be done. This should be merely 'syntactic-sugar-like' however: it shouldn't prevent you from using the communicator in the first place, merely saving you from trying communicators that wont work anyway (but wont crash unpredictibaly).

This is the end - the end

Sorry for the looong post, but I think it's good to share some thoughts on this one ;-) I'll try to come up with more specific implementation ideas / class hierarchies and things soon...

Please comment below for impressions / ideas / comments / etc

Maybe useful to add to the readme:

To install on FreeBSD do the following:

1. pkg install py27-pip
2. sudo pip install mechanize keyring colorama notify2

installing notify2 yields the same error as with travis :/

Something like:

Netlogin openen........... [ OK ]
Oud IP-adres opzoeken..... [   . WA.IT .   ]
Oud IP-adres opzoeken..... [ 10. 92.128.101]
Formulier invullen........ [ OK ]
Gegevens invullen ........ [ OK ]
Gegevens opsturen......... [ OK ]
Uitloggen................. [DONE]

or

Netlogin openen........... [     OK      ]
Oud IP-adres opzoeken..... [    WAIT     ]
Oud IP-adres opzoeken..... [10.92.128.101]
Formulier invullen........ [     OK      ]
Gegevens invullen ........ [     OK      ]
Gegevens opsturen......... [     OK      ]
Uitloggen................. [    DONE     ]

The found IP address should be green. @jovanbulck: what do you think?

Although the CursesCommunicator() was nice to play with, it differs so much from the other Communicators that it is a hassle to keep it up-to-date. Also, it's not crossplatform. I'm thinking of removing it. Thoughts?

You could add a creative commons badge for the correct license in the readme. Looks awesome and communicates the license effectively:

I think the above one is correct and should link to the right version when clicking on it. Here's the markdown:

[![cc-logo](https://licensebuttons.net/l/by-sa/4.0/88x31.png)](https://creativecommons.org/licenses/by-sa/4.0/)

notify2 works great on Linux distros, but it fails to run on Mac OS. I propose to create a wrapper, like the legacy pinger.py, that checks on what OS we are. If we are on Linux, just use notify2. If we are on a Mac, use pync.

This wrapper would just go in the tools directory. All if-else-statements are encapsulated there, so we can just run it from bubblec.py without having to put the if-else there.

We need some a dev testing this implementation. Pinging @Wouter92....

For example: Login afronden...

This would be handy. You'd immediately see whether you were logging out or logging in. It also gives some room to show problems that arose at the last login page.

I was thinking of something like:

xyy: x = action, yy = result. For instance:

100 = login done, no errors
101 = login error, couldn't reach server
102 = login error, credentials incorrect

200 = logout done, no errors
201 = logout error, couldn't reach server
202 = logout error, credentials incorrect

We should check whether we can support Android. Maybe Kivy is the way to go.

Let's assume that most Windows users will use one of our precompiled binaries, without specifying a Communicator.

When you run such a binary, a console will pop up, and it will log you in to KotNet. When the last mesage has printed in the console, the console will close immediately. That means that it's hard to take notice of the current upload/download balance.

Of course, we could write a Qt-based communicator to overcome this. But until we've done that, we should consider writing a timeout. This timeout would require an if-else statement, checking for the OS. We need to put this somewhere. I'd rather not mess up beeindig_sessie() with an if-else-statement. Maybe we can create a SuperBeeindigSessie() and different subclasses?

Credentials moeten geabstraheerd worden; goals:

• ander credential behavior moet ingeplugd kunnen worden: keyring, guest, dummy, ... zijn gewoon andere implementaties van dezelfde abstracte interface / superklasse (bv saveCred, getCred, hasCred, forgetCred). Eventuele toek credentialsystemen met encryptie ofzo kunnen dan ook gewoon inglugd worden
• gebruikersnaam en wachtwoord moeten niet plaintext doorheen de applicatie worden doorgegeven: geef de instantie van de credentialsklasse door en vraag daaraan het ww als nodig
• user input moet niet in de credential klasse worden uitgevoerd, maar in kotnetcli.py, zodat alle user input, 'de command line interface' daar geencapsuleerd is. Een eventuele alternatieve implementatie die de gebruikersnaam en wachtwoord via een gui opvraagt, is dan ook daar mogelijk (evt via subklasse die methode override)

Geschetste flow van kotnetcli.py:

1. eerst switchen op credential vlaggen, om:
   • maak juiste credential klasse aan: KeyRingCred, GuestCred or DummyCred
   • voer eventuele user input (alle user input moet in kotnetcli geencapsuleerd zijn) uit:
     • --guest-mode: vraag creds aan user, saveCreds() (in de GuestCreds klasse)
     • !hasCred(): vraag creds aan user, saveCreds() (in de keyringCreds klasse)
     • --forget: forgetCreds() en exit
2. dan switchen op actie-typen vlaggen, dan:
   • maak juiste worker (== director) instantie aan
   • maak juiste CommunicatorFabriek klasse aan
3. Dan, switchen op communicator related vlaggen:
   • maak juiste communicator aan mbv CommunicatorFabriek klasse
4. Dan alles in gang zetten:
   • worker.go(creds, co)

Zoals merkbaar is kotnetcli dan uiteindelijk een cohesieve, mooie klasse die zich alleen bezig houdt met het parsen van zijn user input vlaggen en de zaak op te starten :-) Door die loskoppeling wordt bv. een gui / alternatieve cli / android app front-end dan vrij triviaal 👍

We should cover, if possible:

• KeyboardInterrupts
• Invalid username/password combination
• Kotnet server unreachable (timeout)
• Kotnet server unreachable (due to being at home)
• Kotnet server unreachable (faulty internet connection)
• Dependencies not installed (ImportError)
• Everything OK, yet not being able to log in due to KotNet restrictions (hard to implement, more testing needed)

the print statements "ik wil inloggen" etc should be toggable with a --debug and/or --nodebug flag

You can still turn debug on by default for developer builds for now, as in jsh if you want to, but users should be able to turn it of if wanted. print statements can be useful for future debugging though