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
-
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