REALMC-11391: Support local-userpass auth provider type for login #244
Conversation
makesitgo
force-pushed
the
REALMC-11391
branch
from
d361975
to
5d05c88
Compare
|
|
||
| At some point, you may wish to configure which Realm and Atlas servers the CLI is connecting to. By default, these URLs point to the Production instances of Realm and Atlas, which should be sufficient for most use cases. | ||
|
|
||
| However, you can set `--realm-url` and `--atlas-url` to any URLs you know a respective server instance is running at. If you are configuring one, chances are you'll want to configure both of these. |
There was a problem hiding this comment.
wouldn't you always need to configure both? not sure how realm dev would work with cloud qa for example
There was a problem hiding this comment.
the one a-typical scenario thats come up in practice is local+dev, but the technicality still remains that you'd be setting both of those at once.
also, if you didn't heed this advice, then you'd read it and say "oh yeah, those chances were right! but now I only need to set one" :)
There was a problem hiding this comment.
I wonder if you could ever rig up a local Realm + prod Atlas env...
| assert.Nil(t, err) | ||
| assert.NotEqual(t, "", session.AccessToken, "access token must not be blank") | ||
| assert.NotEqual(t, "", session.RefreshToken, "refresh token must not be blank") | ||
| }) | ||
| } | ||
|
|
||
| func TestRealmAuthenticateLocal(t *testing.T) { | ||
| t.Skip("this test needs to run with a local Realm server configured to support the local-userpass auth provider") |
There was a problem hiding this comment.
wondering if its worth tying to modify the test_cli.json server config to support local-userpass ... would probably also have to insert a test user, which wouldn't be all that reliable when running the tests locally. any thoughts here from the crowd?
|
|
||
| At some point, you may wish to configure which Realm and Atlas servers the CLI is connecting to. By default, these URLs point to the Production instances of Realm and Atlas, which should be sufficient for most use cases. | ||
|
|
||
| However, you can set `--realm-url` and `--atlas-url` to any URLs you know a respective server instance is running at. If you are configuring one, chances are you'll want to configure both of these. |
There was a problem hiding this comment.
the one a-typical scenario thats come up in practice is local+dev, but the technicality still remains that you'd be setting both of those at once.
also, if you didn't heed this advice, then you'd read it and say "oh yeah, those chances were right! but now I only need to set one" :)
|
|
||
| At some point, you may wish to configure which Realm and Atlas servers the CLI is connecting to. By default, these URLs point to the Production instances of Realm and Atlas, which should be sufficient for most use cases. | ||
|
|
||
| However, you can set `--realm-url` and `--atlas-url` to any URLs you know a respective server instance is running at. If you are configuring one, chances are you'll want to configure both of these. |
There was a problem hiding this comment.
I wonder if you could ever rig up a local Realm + prod Atlas env...
|
test failure is currently related to https://github.com/10gen/baas/pull/5563/files. proceeding with the merge |
Mentioned this in the JIRA, but this functionality was technically missed when going from
v1tov2, see: https://github.com/10gen/realm-cli/blob/support/1.3.x/auth/auth.goNot sure how far we should go to support these use cases of "self-contained Realm instances" when testing in CI/CD environments, but Nikola reached out asking me about this so it's safe to say we have at least one real use-case for all of this