Comments (11)
So currently for V1, authentication has been a huge issue due to the did-jwt implementation
However
It seems V2 is making this 100000x easier and way better based off this document
tldr; you generate a bearer token by signing a message and a few other steps, then request an authentication token
I created a small example of this here: https://github.com/TheLDB/fc-rust-bearer-example
AFAIK the /v2/auth endpoint isnt live/working yet, so theres no way to ensure it works, however it generates the same thing as the JS example in there so :D
any thoughts would be appreciated
from farcaster-rs.
First time seeing that Merkle API v2 document, thanks!
Excellent that you already wrote authentication prototype. Maybe we should create a new branch, v2-api? And start commiting to have something more or less complete for testing when v2 api goes live?
from farcaster-rs.
yeah good idea. having a rough model for when v2 apis go live is important
being the first library to support v2 apis would be super cool
from farcaster-rs.
First time seeing that Merkle API v2 document, thanks!
Excellent that you already wrote authentication prototype. Maybe we should create a new branch, v2-api? And start commiting to have something more or less complete for testing when v2 api goes live?
btw, i pushed some stuff to the v2-api branch, heres a rundown of whats there:
- Added functions to:
- Create a new wallet (relocated from user -> auth)
- Generate a bearer token
- Get a session token
- Added a test route for notifications, not live yet though so unclear if itll work
- Added a constants folder w/ API_ROUTE so we can change one thing and every root route changes just in case
Very happy that authentication is now working, though (see attached photo)
from farcaster-rs.
Very cool Landon!
Since V2 adds HTTP token headers we need to keep track of (apart from rate limits) think we should create abstraction (struct) that wraps reqwest calls. We could then keep both token and rate limit status inside this struct.
What do you think?
from farcaster-rs.
btw good job with extracting API base URL, was thinking of doing exactly that.
from farcaster-rs.
Very cool Landon!
Since V2 adds HTTP token headers we need to keep track of (apart from rate limits) think we should create abstraction (struct) that wraps reqwest calls. We could then keep both token and rate limit status inside this struct. What do you think?
I did create two custom structs (Bearer & Secret) that wrap the bearer token/payload, and the secret token with an expires at, respectively.
I'm open to any suggestions on how to improve this, just couldnt come up w/ much besides that.
To view the types:
https://github.com/TheLDB/farcaster-rs/tree/v2-api/src/types/auth
https://github.com/TheLDB/farcaster-rs/tree/v2-api/src/types/v2
from farcaster-rs.
Already familiar with this :) right now working on encapsulating authentication token using your code. PR soon!
from farcaster-rs.
Already familiar with this :) right now working on encapsulating authentication token using your code. PR soon!
just merged your PR.
since we pretty much have authentication nailed down at this point (maybe some future changes will be needed)
what should the next steps be? just slowly rebuilding calls/endpoints to call merkle endpoints vs the current ones?
if so, how should that look? was thinking of taking it section by section, archiving the old calls, writing new ones, then deleting the old ones after v2 has been tested
then, when v2 goes fully live, we can polish & publish super fast
from farcaster-rs.
since we pretty much have authentication nailed down at this point (maybe some future changes will be needed)
Hold on, there's one more big thing incoming :)
When speaking about higher level abstractions and encapsulation i meant more structured API from crate user point of view. Majority of my last PR is to prepare for new FarcasterAccount struct - abstraction of account used behind the scenes to obtain Merkle API authentication token, signing messages etc.
I think we need more structure as opposed to tons of unstructured, public functions implemented under Farcaster.
The way you would use FarcasterAccount is something like this:
let account = FarcasterAccount::from_mnemonic("highly secret mnemonic phrase ...");
let farcaster = Farcaster::new(ethereum_provider, account);
In addition to from_mnemonic() you can use from_private_key() - both implemented using your code. Serializing/deserializing to disk could also be implemented (security considerations though).
Behind the scenes FarcasterAccount uses auth code you wrote to prepare Bearer token and get/refresh Session token when needed.
It should fit nicely with a new "proxy" struct that could wrap all reqwest calls to add auth headers and keep track of rate limit headers etc.
what should the next steps be? just slowly rebuilding calls/endpoints to call merkle endpoints vs the current ones?
if so, how should that look? was thinking of taking it section by section, archiving the old calls, writing new ones, then deleting the old ones after v2 has been tested
The way i see it:
- integrate types/v2
- everything that breaks compilation (mostly get_*) - comment out for now (or even rm)
- (optional) write reqwest proxy struct
- start adjusting/replacing endpoint calls one by one (Casts, Notifications etc.)
- when v2 goes live: v2-api -> main
from farcaster-rs.
Just pushed another PR that includes FarcasterAccount. Let me know what you think.
from farcaster-rs.
Related Issues (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 farcaster-rs.