Replies: 1 comment
-
// This method should allow to retrieve a field content
// directly through lightning network.
// A field protected approach can be interesting yet it raise some
// issues :
// - It can be an seen as an anti-pattern according to gql specs
// - LN request payment association with list of objects seems challenging
#[graphql(ignore)]
async fn public_url<'a>(
&self,
context: &'a GQLContext,
#[graphql(description = "The payment request associated to the media.")]
payment_request: Option<String>) -> FieldResult<Option<String>> {
let user = context.get_user();
let a = env::temp_dir();
match user {
Some(user) => Ok(Some(a.to_string_lossy().to_string())),
None => {
match payment_request {
Some(payment_request) => {
let connection = context.get_db_connection();
let media_payment = connection.run(move |c| MediaPayment::find_one_by_request(payment_request,c)).await;
match media_payment {
Some(payment) => {
match payment.media_uuid == self.uuid {
true => {
match InvoiceUtils::get_invoice_state_from_payment_request(context.get_lnd_client(), payment.request).await {
Ok(invoice_result) => match invoice_result {
Some(invoice) => match invoice.state() {
InvoiceState::Settled => Ok(Some("".to_string())), // Payment has been done. Serves the post
InvoiceState::Open => Err(FieldError::new(
"Awaiting for payment to be done.",
graphql_value!({"state": "open"}),
)), // Payment hasn't been done yet. We shall wait for payment, so there's no need to regenerate an invoice
InvoiceState::Accepted => Err(FieldError::new(
"Payment ongoing but not settled yet",
graphql_value!({"state": "ongoing"}),
)), // Payment is on process onto the network but has not reach its receiver yet. We shall wait, so there's no need to regenerate an invoice
InvoiceState::Canceled => Err(self.generate_invoiced_error(context,"Payment expired or canceled.").await),
},
// LND Server says there's no invoice matching
None => Err(self.generate_invoiced_error(context,"No invoice found for corresponding payment request. Proceed to payment with the provided request payment").await)
},
// Invoice is broken. Maybe we should serve a new invoice here ?
Err(_) => Err(FieldError::new(
"An error happened when trying to decode invoice",
Value::null(),
)),
}
},
false => Err(FieldError::new("",graphql_value!("")))
}
},
None => Err(FieldError::new("",graphql_value!("")))
}
// Ok(a.to_string_lossy().to_string())
},
None => Err(FieldError::new("",graphql_value!("")))
}
}
}
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
While experimenting with GraphQL and LN implementation i drafted a method to protect field resolving through LN payment.
The main idea was to expect an argument, that would refer to the LN payment, onto a field to condition the field resolver result.
This approach raises some issues and could be seen as some kind of anti-pattern, moreover if we consider the resolver conditioning through payment as an authorization system.
Below is an example of the structure that could be written with juniper to implement such mechanism :
Beta Was this translation helpful? Give feedback.
All reactions