Update README.md

README.md

@@ -80,15 +80,35 @@ Meteor.startup(() => {
 In the long run, the goal is to transition the Meteor backend to Next as well, using Next API routes.
 
 - Next is configured to use the same Mongo database as Meteor locally. To get the URL of the local Meteor database, run `meteor mongo -U`. It's most probably something like this: `mongodb://127.0.0.1:3002/meteor`
-- TODO: in Next, configure Passport to authenticate users using the existing Mongo database from Meteor.
-Vulcan Next now provides authentication.
-To update password:
-    - In Vulcan Meteor, hashed password lives in `services.password.bcrypt`
-    - You need to split this value like this: 22 characters after the 3rd $ is the `salt`. The rest is the `hash`. You can ignore the beginning.
-    Example: `$2b$10$abcdefghijklmnopqrstuvWXYZ123456789` => `salt` is `abcdefghijklmnopqrstuv` and `hash` is `WXYZ12345678`
-    - Store the `hash` in `hash` and `salt` in `salt` in the user document.
-
- If it doesn't work, simply alter Vulcan Next password check method so it fall back to `services.password.bcrypt` to find the hashed password, see https://willvincent.com/2018/08/09/replicating-meteors-password-hashing-implementation/
+
+- You can use both Next's GraphQL API and Meteor's GraphQL API using the [Connect to multiple graphql API in the frontend pattern described here](https://github.com/VulcanJS/vulcan-next/blob/demo/with-meteor-backend/src/content/docs/recipes.md)
+
+
+### Reuse the meteor database 
+
+See https://github.com/VulcanJS/vulcan-npm/issues/63. 
+Meteor uses string `_id` as a default, while Mongo uses `ObjectId` type, so you need to do `ObjectId.str` to get the actual id or use a method like `isEqual` from lodash. **This means that objects created using Next backend might create bugs in the Meteor backend**. You need to avoid that, by doing creation operations only in Meteor, or to clearly separate things you manage in Next and things you manage in Meteor until you have fully transitionned.
+
+### Reuse existing user
+
+- If you plan to reuse your existing Meteor database in Next, this means you might need to parse all documents and change the "string" `_id` to an `ObjectId`, see https://forums.meteor.com/t/convert-meteor-mongo-string--id-into-objectid/19782.
+You can change the `_id` generation scheme (see https://docs.meteor.com/api/collections.html) to ObjectId in the Meteor app if you need a progressive transition.
+TODO: We still have an issue with `function convertIdAndTransformToJSON<TModel>`, it tries to access `document._id` for string conversion but it seems to be undefined when using a Meteor Mongo database.
+**Current workaround:**: clone users manually in Compass, it will recreate an id as an ObjectID https://docs.mongodb.com/compass/current/documents/clone/
+**Better workaround**: force mongoose to use string ids in the Vulcan Next model https://forums.meteor.com/t/using-mongoose-to-query-a-mongo-db-that-was-from-a-meteor-db/53789
+There is an example "user.server" model in Vulcan Next
+
+
+
+
+
+
+#### Check the existing password
+
+
+Simply alter Vulcan Next password check method so it fall back to `services.password.bcrypt` to find the hashed password, see https://willvincent.com/2018/08/09/replicating-meteors-password-hashing-implementation/
+
+This is already done in Vulcan Next latest version.
 
  Example structure of a user:
  ```json
@@ -139,18 +159,21 @@ To update password:
 };
 ```
 
+#### Attempt to update password
+
+/!\ This doesn't work as expected, probably because Meteor is using SHA256 and Vulcan Next SHA512. Instead, update the password field only when the user change their password.
+
+
+To update password:
+    - In Vulcan Meteor, hashed password lives in `services.password.bcrypt`
+    - You need to split this value like this: 22 characters after the 3rd $ is the `salt`. The rest is the `hash`. You can ignore the beginning.
+    Example: `$2b$10$abcdefghijklmnopqrstuvWXYZ123456789` => `salt` is `abcdefghijklmnopqrstuv` and `hash` is `WXYZ12345678`
+    - Store the `hash` in `hash` and `salt` in `salt` in the user document.
+  
+
 
-- You can use both Next's GraphQL API and Meteor's GraphQL API using the [Connect to multiple graphql API in the frontend pattern described here](https://github.com/VulcanJS/vulcan-next/blob/demo/with-meteor-backend/src/content/docs/recipes.md)
-- TODO: See https://github.com/VulcanJS/vulcan-npm/issues/63. 
-Meteor uses string `_id` as a default, while Mongo uses `ObjectId` type, so you need to do `ObjectId.str` to get the actual id or use a method like `isEqual` from lodash. **This means that objects created using Next backend might create bugs in the Meteor backend**. You need to avoid that, by doing creation operations only in Meteor, or to clearly separate things you manage in Next and things you manage in Meteor until you have fully transitionned.
 
-### Reuse the meteor database 
 
-- If you plan to reuse your existing Meteor database in Next, this means you might need to parse all documents and change the "string" `_id` to an `ObjectId`, see https://forums.meteor.com/t/convert-meteor-mongo-string--id-into-objectid/19782.
-You can change the `_id` generation scheme (see https://docs.meteor.com/api/collections.html) to ObjectId in the Meteor app if you need a progressive transition.
-TODO: We still have an issue with `function convertIdAndTransformToJSON<TModel>`, it tries to access `document._id` for string conversion but it seems to be undefined when using a Meteor Mongo database.
-**Current workaround:**: clone users mnually in Compass, it will recreate an id as an ObjectID https://docs.mongodb.com/compass/current/documents/clone/
-**Better workaround**: force mongoose to use string ids in the Vulcan Next model https://forums.meteor.com/t/using-mongoose-to-query-a-mongo-db-that-was-from-a-meteor-db/53789
 
 
 ## Caveats