| Commit message (Collapse) | Author | Age |
| |
|
|
|
| |
That helps remove duplicated code and rustc/cargo will now also show
dead code correctly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We rely on the user to manage their keys. This is ok, and is
intentionally part of our security model
However. If the user messes up, they corrupt their remote store. It is
possible to work around and fix, but not without difficulty. This change
ensures that if the local key does not match the remote data, no data is
synced and the user has a chance to fix it before breaking things.
## Checks
- [ ] I am happy for maintainers to push small adjustments to this PR,
to speed up the review cycle
- [ ] I have checked that there are no existing pull requests for the
same thing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
## Summary
This PR enables the Atuin CLI to authenticate with Atuin Hub, unifying
authentication across CLI sync and Hub features (AI, runbooks, etc.).
### Key Changes
- **Dual auth support**: New `AuthToken` enum supports both `Bearer`
(Hub) and `Token` (legacy CLI) authentication
- **Smart protocol selection**: New `sync_protocol` setting
(`auto`/`hub`/`legacy`) determines auth method. By default,
`api.atuin.sh` uses Hub auth; custom sync addresses use legacy auth
- **Hub login flow**: `atuin login` now initiates an OAuth-like flow for
Hub users—generates a code, user authorizes in browser, CLI polls for
completion
- **Account linking**: After Hub auth, silently attempts to link
existing CLI sync account to Hub account for seamless migration
- **Graceful fallback**: `sync_auth_token()` prefers Hub token when
available, falls back to CLI session token
### Auth Flow
1. User runs `atuin login` (with default sync address)
2. CLI requests auth code from Hub, displays URL
3. User opens URL, logs in/registers on Hub
4. Hub attaches API token to code
5. CLI polls, receives token, saves as hub session
6. If user had existing CLI sync account, it's automatically linked
### Backward Compatibility
- Existing self-hosted users: unaffected (legacy auth via `Token`
header)
- Existing `api.atuin.sh` users: continue working with CLI session until
they run `atuin login`
- New users: go through Hub flow automatically
## Test Plan
- [ ] New user registration via Hub flow
- [ ] Existing CLI user can still sync without changes
- [ ] `atuin login` links CLI account to Hub account
- [ ] Self-hosted users unaffected by changes
- [ ] AI commands work after Hub auth
---------
Co-authored-by: Ellie Huxtable <ellie@elliehuxtable.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These files have been known to have corruption issues. SQLite will
perform better across filesystems for reads/writes across threads, and
will lock as expected.
I've also put the session file in there, though I'm 50/50 on it - I'll
be replacing it with keyring storage asap anyway.
The key file is _not_ included. It should ~never be changed, and should
be easy for the user to secure + manage themselves
In the future, instead of creating more files, we can just use this as a
kv store
Resolves https://github.com/atuinsh/atuin/issues/2336, resolves
https://github.com/atuinsh/atuin/issues/1650
## Checks
- [ ] I am happy for maintainers to push small adjustments to this PR,
to speed up the review cycle
- [ ] I have checked that there are no existing pull requests for the
same thing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a parameter to change the upload/download page size, this
could help if one gets a '413' in a selfhosted scenario.
## Checks
- [x] I am happy for maintainers to push small adjustments to this PR,
to speed up the review cycle
- [x] I have checked that there are no existing pull requests for the
same thing
---------
Co-authored-by: Ellie Huxtable <ellie@elliehuxtable.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We had an issue where the server was returning an empty page, when it
should not, and causing the client to keep looping
While such bugs should not happen, putting the client into a loop does
not help
## Checks
- [ ] I am happy for maintainers to push small adjustments to this PR,
to speed up the review cycle
- [ ] I have checked that there are no existing pull requests for the
same thing
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* chore: upgrade to 2024 edition
* ugh unsafe
* format
* nixxxxxxxxxxx why
|
| |
|
|
|
|
|
|
|
|
|
| |
Check atuin setting paths (eg. `db_path`) for broken symlinks on
initialization and disable all shell hooks + print error message.
sqlite doesn't create db files even with `.create_if_missing` when the
db files are a broken symlink. This would cause sqlite to error and
atuin to panic on every single keypress.
Also improves related error handling when calling atuin client commands
directly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* test: add env ATUIN_TEST_LOCAL_TIMEOUT to control test timeout of SQLite
This make it possible to control the timeout of SQLite operations in
test. And ATUIN_TEST_LOCAL_TIMEOUT defaults to the default local_timeout,
which is actually used in the client. Instead of a small timeout (0.1),
this change makes the test less likely to fail and better imitate the
default behavior.
SQLite operation timeout was first introduced from #1590, including
connection and store timeout. The env ATUIN_TEST_SQLITE_STORE_TIMEOUT
which added by #1703 only specify the store timeout. This commit doesn't
deprecate ATUIN_TEST_SQLITE_STORE_TIMEOUT, but control it by setting its
default to the new env ATUIN_TEST_LOCAL_TIMEOUT.
* test!: replace ATUIN_TEST_SQLITE_STORE_TIMEOUT with ATUIN_TEST_LOCAL_TIMEOUT
This deprecate ATUIN_TEST_SQLITE_STORE_TIMEOUT for simplicity as the new
env ATUIN_TEST_LOCAL_TIMEOUT can control both connection and store
timeout of SQLite in test. Details see 4d88611.
Revert: #1703.
|
| | |
|
| |
|
|
|
|
|
|
| |
* fix(daemon): do not try to sync if logged out
I've also added Settings::logged_in, as there are a few places where we
switch on login state.
* make session_token a function
|
|
|
I'd like to tidy up the root a little, and it's nice to have all the
rust crates in one place
|