Comments (24)
It's fine for me, add authentication check is quite easy.
from caprover-cli.
@drmrbrewer
Correct. This wrong password issue hasn't been addressed yet.
from caprover-cli.
My vote is for @githubsaturn as President of the Universe. Back more on topic, I think your summary is pretty much in line with my feelings expressed above (e.g. in the post just above yours) in that the auth check is different to asking for missing defaults as such. So apart from voting for @githubsaturn as POTU, my vote is to re-instate the auth check.
from caprover-cli.
I don't think this change was intentional. I'll look into it. You can always go back to the previous version via npm install -g [email protected]
@Hazzard17h was this an intended change?
from caprover-cli.
Have reverted to 1.2.0
for now. Much better experience... get the following instead:
Your auth token is not valid anymore. Try to login again.
? Please enter your password for https://captain.myserver.mydomain.com
from caprover-cli.
Having upgraded to 2.0.2
to check that it addresses this issue (it does seem to), I can confirm that the issue reported here is back again (i.e. just bombing out if auth token is no longer valid rather than asking for password again). So I'm reverting to 1.2.0
again for now.
from caprover-cli.
This was an intended change.
Basically, if we are re-deploying with --default
, we want that all deploy configs are in the context, and we don't want user interaction.
If you think than must be done the authentication check (token check and ask password if expired), I can add it.
from caprover-cli.
Personally I'd find it very useful to have the behaviour as per v1... or at least have an option for it, i.e. to allow user interaction in the specific case where the auth token for accessing the caprover server is no longer valid. It enables me to do a quick caprover deploy -d
(as part of a longer script that also performs other step like git commit
etc), knowing that it will just ask me for the password if the current caprover server auth token is no longer valid. It would be a right royal pain to have to re-authenticate via another step, perhaps only 10 mins later when I come back to the terminal to discover that the deploy didn't complete. And I don't want to store my password in the script (coupled with the --pass
option).
from caprover-cli.
IMHO, to use deploy in a script, the best option is -c config.json
, to be sure that it doesn't break.
from caprover-cli.
IMHO, to use deploy in a script, the best option is
-c config.json
, to be sure that it doesn't break.
According to the docs, -c
is not even an option.
from caprover-cli.
According to the docs,
-c
is not even an option.
Please, see updated docs related to the use of CLI, on the readme of this project: all commands accept -c configFile
.
from caprover-cli.
Thanks. Still requires storing passwords in a file, though. Which the CLI v1 deploy -d
method doesn't.
from caprover-cli.
Thanks. Still requires storing passwords in a file, though. Which the CLI v1
deploy -d
method doesn't.
You could omit the password from config file, and CLI will ask for it if token is expired. But I don't figure why automatic deployment must involve user interaction...
from caprover-cli.
could omit the password from config file, and CLI will ask for it if token is expired
Why can't this logic apply to -d
as well?
don't figure why automatic deployment must involve user interaction
In my case it's not automatic as such... I'm still sat at the terminal but I just run a single command (script) rather than several.
Something like:
./deploy 'some changes'
rather than:
git add -A .
git commit -m 'some changes'
git push origin master
caprover deploy -d
from caprover-cli.
Why can't this logic apply to
-d
as well?
Because -d
is treated differently from other options, as said in the help: "use previously entered values for the current directory, no others options are considered".
If you think that must be done the authentication check (token check and ask password if expired), I can easily add it. But i don't think this is the intended functionality of -d
.
In my case it's not automatic as such... I'm still sat at the terminal but I just run a single command (script) rather than several.
You can archive the same result updating the script to call caprover deploy
expliciting deploy params, using -c config
or directly needed options: -n caproverMachine -a app -b master
.
from caprover-cli.
You can archive the same result updating the script to call
caprover deploy
expliciting deploy params
Though if you don't want to store passwords in config files then you need to enter the password every time? With the v1 behaviour of the CLI you enter the password once and then only again when the auth token is no longer valid, which may be a looong time... which is very convenient.
from caprover-cli.
Just seems sensible and logical and helpful to be able to use defaults where available and if a piece of information is not available from defaults then ask for that missing of information. Like for -c
. I'm not sure why there should be a distinction between -d
and -c
in this respect, regardless of what the docs currently say.
from caprover-cli.
Though if you don't want to store passwords in config files then you need to enter the password every time? With the v1 behaviour of the CLI you enter the password once and then only again when the auth token is no longer valid, which may be a looong time... which is very convenient.
No, if you store caproverName
in the config, it try to reuse the auth token of that machine, and ask for a password only if it is no longer valid.
from caprover-cli.
OK. But what is the logic behind asking for it when using -c
but not asking for it when using -d
?
from caprover-cli.
The point is not -d
vs -c
, but how to handle -d
without breaking things or have strange behaviors.
What if I use caprover deploy -d -u url
? Or caprover deploy -d -i image
, and previously used value is a branch and not an image?
As I said before, I could add the authentication check, but -d
must be treated separately.
from caprover-cli.
how to handle
-d
without breaking things or have strange behaviors
Asking the user to enter the server password again IMHO is neither breaking things (it was like that in v1 so if anything it is not breaking things) and also it is not a strange behaviour. When using -d
you're telling the CLI to use the previously-entered values, and the server name and password haven't changed since the last time you ran caprover deploy
, so it is trying to use the previously-entered values as requested... the reason why in v1 it asks for the password again is (as I understand it) not because the password has changed (my server password has never changed) but because the auth token is no longer valid (e.g. because caprover restarted). The message in v1 is Your auth token is not valid anymore. Try to login again.
So it seems reasonable and normal and not strange to be asked to authenticate again.
from caprover-cli.
Late to the party here. But here is my 2 cents:
- Previously
-d
option, would use any previously entered/known values, if not known, or not valid, then it would ask the user. - With the new implementation, it assumes everything should be previously known / valid.
In general, I prefer the new behavior as it reduces the chance of wrongfully deploying over another app and other human errors. However, there is one exception to it, and that is the Auth Check.
I believe we should add back the auth check to the -d
. The reason behind that is that the Auth Token can be expired via a simple server restart. The intended usage of -d
is not for automation, it's for everyday development use. Without the auth check being integrated into the -d
option, in case of a server restart, user has to enter everything again... quite frustrating...
So my suggestion is to keep things like they are, and just add the authentication check into the flow. Unless this creates a logical mess, I think this is the way to go.
@Hazzard17h / @drmrbrewer thoughts?
from caprover-cli.
See #33
from caprover-cli.
Fixed in #33 and released as 2.1.0
from caprover-cli.
Related Issues (20)
- Confusing dashboard button aspect HOT 5
- Docker image v2.2.3 is missing
- Error "Cannot find hash of last commit on branch" HOT 18
- PR approved pending publication in NPM HOT 1
- caprover deploy: Cannot find hash of last commit on branch "master" caused by git as root error HOT 12
- GitLab CI/CD Issue HOT 2
- Error: manifest for node:18.00-alpine not found HOT 2
- stuck/hangs when deploying HOT 1
- -t option is used with tarFile and appToken HOT 1
- Something bad happened during authentication HOT 1
- captain-definition file is not a valid JSON! HOT 6
- Fetching build logs when using app access token HOT 2
- Caprover backup using CLI HOT 2
- How to see users in localMachine and change ip? HOT 1
- Is it possible to use --caproverUrl without domain ? HOT 1
- Git error messages are hidden when getting error on a branch
- Error: self signed certificate (Local network) HOT 1
- Title: Issue with Constant.ts file not reflecting environment variable override in built Constants.js HOT 1
- Add environment variables via deploy
- updateConfigAndSave missing some methods
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 caprover-cli.