Menu
▾
▴
#111 CItizen Sky login should be optional
closed-fixed
9
2013-03-16
2010-01-06
No
When a user wishes to load files (simple and AAVSO download format), no Citizen Sky login details are required. This was a conscious decision early on in the project to permit "offline" usage of VStar. The reality is that AID and VSX database database (JDBC) connection details are *required* for accessing observation data, while Citizen Sky database connection (aka login) is in fact, only required for obtaining observer code. It was also listed early on as an authentication requirement, but I believe that for maximum acceptance and usability of VStar, ultimately this should be considered optional.
The user's observer code or indeed, any known observer code (which can be obtained by clicking any observation point on a light curve or looking in the observation list table view) could be entered into a text box in order to cause an observer's observations to be highlighted.
I'm not saying this is necessary in the short term, but I do think we should ultimately permit this since VStar, I hope, will be used by people who, for whatever reason, won't sign up with Citizen Sky.
See also https://sourceforge.net/tracker/?func=detail&atid=1152052&aid=2953491&group_id=263306 which has been closed as a duplicate.
Sara and I discussed this again yesterday. It would be good to resolve this before the Oct 2010 VStar workshop at the AAVSO meeting.
After sleeping on it, here's what I propose:
a. Login be removed as a requirement for database loaded observations.
b. A preferences tab be added to allow a user to authenticate against Citizen Sky (with same dialog as is used now) or AAVSO (to be added). See also https://sourceforge.net/tracker/?func=detail&aid=2998232&group_id=263306&atid=1152052 re: the latter.
To be clear, in the proposal below, b. is intended just so that the observer code can be extracted from the database (Citizen Sky or AAVSO) so it can be pre-populated in filtering operations.
If we do this, the need for saving username/password client side becomes much less important; see https://sourceforge.net/tracker/?func=detail&aid=2949807&group_id=263306&atid=1152052 re: this.
Implemented at http://vstar.svn.sourceforge.net/viewvc/vstar?view=revision&revision=617
The login dialog now only pops up when:
An AID dataset has been loaded and one of the following is true:
1. An observer code filter is selected (to retrieve obscode).
2. An observation is marked as discrepant (to verify user name).
Authentication sources are tried in turn (AAVSO, CS).
Once authenticated, VStar will not ask the user to login again for a given session.
David, After some practice with this new feature - of not needing to log in unless one of the two conditions you mentioned are met. i.e.
1. An observer code filter is selected (to retrieve obscode).
or
2. An observation is marked as discrepant (to verify user name).
I would like to propose that we do away with condition #1 because typing in one's username & password is more work than just typing in one's own obscode itself. It is my impression that most people know their own obscode better than their login username & password anyway, so I can't really think of an advantage to having to log in just to populate that filter table. Please correct me if you think I'm missing something...
Hi Sara. I'm not violently opposed to that proposal. :)
I have to admit that I do also like the idea of being able to retrieve my observer code, although you're right: people are likely to know it already so it's not a big deal. A few comments:
o You can of course just cancel the dialog box. :)
o VStar will only ever ask you to authenticate once per session (and only once for either of the reasons of obscode retrieval or discrepant reporting).
o Only if the obscode filter term is selected will you be asked to authenticate, not some other filter term.
o Authentication will never be required unless you have loaded from AID.
Should we post on CS (the above conversation perhaps) about it and if no-one gives a good reason why obscode selection should require login, then let's just remove it?
Sara and I have discussed this further and we both agree that the way things are is not ideal. Then I remembered that I was going to add a Preferences pain for obscode. We could even do this for user name (for discrepants), so this could become an authentication prefs pane. Observer code and user name could be stored as preferences.
We really only need Observer Code OR Username for reporting discrepant observations. The main thing is that they need to be valid ones so we can look them up in the members table and know who they really are.