I’m new to Spark… I’m a sysadmin who supports a hybrid environment where we run both Red Hat Linux and Windoze operating systems, so my question will potentially apply to both. We authenticate both operating systems through Active Directory.
I work in an environment (think ‘DoD’) where saved passwords (especially in clear text) are a no-no. I have tested a few chat clients (pidgin, swift) and both save passwords in cleartext. Detailed documentation on Spark is pretty hard to find in my experience, however it appears from what I have found that Spark has the ability to hide the “Save Password” checkbox (my first choice) and/or encrypt the password (my last choice). The reason I would prefer to simply make the “Save Password” box dissapear is to eliminate the flood of tickets that will come whenever a user is required to change their AD password and that change conflicts with the saved Spark password. I’d like to eliminate that issue completely.
My problem is I cannot find anything in the forum (or anything at all) which describes how to hide that checkbox. I have not explored it on the Windoze side yet, but I have scoured through the saved files on the Linux side ($HOME/.sparkExt.properties) and have not found anything I can modify there. Can someone help me with this? IF it can be done, we’ll adopt Spark across the organization. If not, I’ll keep looking for something else.
One way to deal with that is to setup SSO, so users won’t have to type passwords at all. But that can be tricky (i have never tried to do this myself). How To: Video on setting up SSO/AD with Openfire
If you are using Openfire as a server, then you can use Client Control plugin (for Openfire), which has an option to disable Save Password and Auto-login checkboxes in Spark.
That’s exactly what I was looking for! Thank you, thank you, thank you!!! We have relied on Openfire for several years. It has worked out very well for us. The problems started when our cyber security folks made us ditch Pidgin because it stores passwords in clear text.
I installed the latest version of Openfire when setting up this particular network. Swift looked like a logical choice since the DoD was already using it in some organizations. However, it too stores passwords in clear text, so that was a “no”. Spark looks like it will serve our needs well, especially if I can get the Client Control plugin working. That will be the preferred route in my case.
Thank you again for the quick and concise reply. I owe you one…
Starting to deploy and test Spark… and found there is apparently a work-around to disabling ‘save password & autologin’ in the Openfire Client Control plugin. Once those options are hidden on the login menu, users can still access them by going through the ‘preferences’ menu. I can disable the ‘preferences’ menu through the Openfire Client Control plugin, but that also locks users out of a lot of other settings (like spell check).
For now I’m disabling users’ access to the preferences menu. Is there a chance the Openfire Client Control plugin could disable ‘save password & autologin’ in both places without having to disable all of the preferences at the same time?
This may not be the place to ask this - if not, could someone point me in the right direction?
This is the right place to ask. Actually, users would still be able to enable Save Password by manually editing spark.properties file and adding a line. Well, only sophisticated users would do that, but then they can share this with others. These Client Control settings are of “security through obscurity” type and it needs a major reworking to make it work properly.
I have filed a few tickets (for Spark and for Client Control as changes has to be done in both for new settings or changes in settings). But it can’t be applied retroactively to the current version of Spark. So it will only be changed in the next version. Unfortunately Spark is currently in a development stall (there are no devs to fix current major issues with 2.9.0). So i can’t tell when it will be released.
These changes are easy enough so i might be able to do them myself.
This would be perfect! Most of my users don’t know enough to go in and tweak the settings file in their home directory. For the ones who do… their computers may suddenly start experiencing unexplained mid-day reboots… lol
Actually, i have just discovered another workaround. To login once to some public server, which uses Openfire and doesn’t have Client Control. Then all restrictions are removed. Then login to your server and set Save Password Because restrictions are enabled only after first login after setting them. Of course, this is also very unlikely to happen.
I have done change on Spark’s side. There are two ways to control restrictions in Spark. Old one: via default.properties file inside Spark.jar. These settings have since been duplicated in Client Control plugin. In default.properties variant it actually disables settings in Preferences too. This has not been reflected for the Client Control variant. Pretty simple one line fix.
Later will update Client Control plugin, although it will work with current plugin version as no logic change was needed on plugin’s side. Just need to update a few descriptions and add explanation to changelog.
But as i’ve said, this will only work when Spark 2.9.0 is released (eventually).
I wish I could test this, but I’m setting this up on several air-gapped networks. Can’t get to any publis servers unless I create another Openfire server for this one task. I think the process would be too confusing for my users though. When asked; many of them don’t even know if they log into a Windows machine or a Red Hat workstation every day. (sad, but true)
I have to say this though; the opensource community is amazing. I cannot believe you jumped on this so quickly. I will patiently wait for 2.9.x. In the mean time, I will bludgeon my users with a heavy blunt object if they lock their accounts because that had ‘save password and autologin’ selected when the setup instructions I posted on our Wiki specifically tell them not to!
Because restrictions are enabled only after first login after setting them. Of course, this is also very unlikely to happen.