Comments (7)
Thanks for the update.
I agree that xdg_config_home
would be a good place for the dotfiles.
Usually, the command is able to invoke whatever external tool one uses, a common use being pass
. So the idea would be to have a line in the config that looks like PassCmd /usr/bin/pass entry.name@email
. Makes sense?
from zulip-terminal.
Thanks for the inquiry! Is this a blocker to you being able to use Zulip or Zulip-terminal?
I wasn't familiar with mbsync
, and it took me a while to figure out what you meant by a 'pass command', since I wasn't familiar with that tool either :)
My understanding of your query is that you're wanting to store the password-like detail centrally in a pass
password store, and extract it on-demand upon starting the application?
Currently zuliprc
(-style) files generated by the Zulip web app have the form of:
[api]
email=... # login (email or username)
key=... # key
site=... # server
Zulip-terminal uses the python zulip wrapper library, and further details on the structure of this kind of zuliprc file is at:
https://github.com/zulip/python-zulip-api/tree/main/zulip (README.md)
As a client we could implement this feature individually, since we could support arbitrary features/extensions in a zuliprc file, a little like we do right now for our current options. However, if we added such an option, we may want to coordinate with the larger community to coordinate on this.
The Zulip server supports other login methods that we have yet to incorporate, which are typically browser-based, and mostly about connecting to a central authority (see eg. https://zulip.com/help/configure-authentication-methods). My understanding is that your request is specifically for a local authentication feature; the reason I mention this is I'm wondering if the deferral of the authentication to a command might be a common factor to both if we implemented these.
from zulip-terminal.
Thanks for looking at this, and sorry for being cryptic. You got me right.
I'm mostly concerned with local auth, but indeed a pass cmd could also deal with tokens.
My concern is that I don't want to store key material in the config (zuliprc), so that it can be checked in git with other dotfiles.
To keep the analogy with mbsync, the token case (for oauth) has PassCmd "~/bin/mutt_oauth2.py ${XDG_DATA_HOME}/oauth-tokens/gmail.tokens"
.
from zulip-terminal.
To be unambiguous: the pass cmd
option shuold let us use pass
, gopass
or whatever else we can use from the terminal.
from zulip-terminal.
@dkwo To confirm the original intent here:
- the zuliprc could be in a standard location (enabling eg.
.config
in git, as per #678) - the private password/token could be stored in a separate encrypted location
- the zuliprc would have some way to point to a command that starts the extraction of the appropriate password/token (presumably prompted), rather than embedding it in the zuliprc file (ie. a
PassCmd
or equivalent)
Based on how we currently include zulip-terminal configuration as extra data in the zuliprc, the above would seem the approach to take.
However, we're hoping to look at #678 this Summer, and there are benefits from separating the client config from the bare zuliprc (with only the [api]
section). For example, if one resets the API key then the file could be easily updated separately from config, and central config could be distinct from per-server config. If this separation was achieved, could the 'private' location you use also store the details in the [api]
section in such a way that it would be easily integrated with an application?
If so, the bare zuliprc downloadable from Zulip (or via the API, or zulip-terminal) could be placed in the more secure location, with a redirection like PassCmd
for the entirety of the login. Is that an established approach with these tools?
from zulip-terminal.
@dkwo Thanks for your feedback so far, and it's absolutely fine to continue clarifying the requirements here, but just to let you know: I started a discussion on chat.zulip.org regarding this here, since this could be relevant for other code generating and consuming zuliprc files.
from zulip-terminal.
Re my last paragraph/question in this comment, I saw that pass
can handle some extra data, but I wasn't sure how transparently it could handle eg. an entire normal zuliprc (without zulip-terminal data) - or other similar tools.
from zulip-terminal.
Related Issues (20)
- Handle new/empty direct message narrows better HOT 4
- Support the set of features related to following topics
- UI bugs from external pinning/unpinning stream events
- Support autocomplete of wildcard mentions
- Improve user issue reporting - add copy feature to About popup
- Unreliable test for typing notifications
- 'All messages' are not consistently accessible compared to P/#/f HOT 1
- Improve handling of narrows (views) with no messages HOT 1
- Adjust test and code locations to match (UI) HOT 1
- Migrate from 'Stream' to 'Channel' naming
- Summarize the code architecture
- Specify Zulip coding conventions/styles/approaches ZT follows
- TRACKING: Improve hotkey descriptions, categories & accuracy HOT 1
- Add web app hotkeys for message formatting during compose HOT 1
- Review & improve ordering of autocomplete (users/mentions)
- Add documentation for developing new features against the API
- Fully resume autocomplete if choosing to resume compose from confirmation popup
- Use common-background code to enable variants of themes (eg. gruvbox contrast settings)
- Add current terminal window size to About popup HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zulip-terminal.