Forward real IP in internal-api client calls #72

Merged

anbsky merged 2 commits from feature/remote_ip into master

2019-09-20 08:52:08 +02:00

anbsky commented

2019-09-18 13:04:36 +02:00

(Migrated from github.com)

This is to add X-Forwarded-For header for calls originated from lbrytv server so internal-apis can correctly log the original IP of the client accessing lbrytv.

This is to add `X-Forwarded-For` header for calls originated from lbrytv server so internal-apis can correctly log the original IP of the client accessing lbrytv.

tiger5226 (Migrated from github.com) approved these changes 2019-09-19 21:45:05 +02:00

tiger5226 (Migrated from github.com) left a comment

It would be nice if we could have declared response objects instead of the generic ones. So that we can just use this in a library without much thought. There is overhead in keep the api responses aligned but I think its worth it in the long run and its not that much extra work since there is only one. However, its not required for merging.

Also the user object path is hardcoded and I am not sure why. Maybe its a const for some other change?

anbsky commented

2019-09-20 08:51:05 +02:00

(Migrated from github.com)

It would be nice if we could have declared response objects instead of the generic ones. So that we can just use this in a library without much thought. There is overhead in keep the api responses aligned but I think its worth it in the long run and its not that much extra work since there is only one. However, its not required for merging.

I don't disagree but for that the API should be versioned and documented, of which this API is unfortunately neither. In the absence of versioning, a simple removal of field will break the whole chain of clients in a far away code, and we don't want that.

> It would be nice if we could have declared response objects instead of the generic ones. So that we can just use this in a library without much thought. There is overhead in keep the api responses aligned but I think its worth it in the long run and its not that much extra work since there is only one. However, its not required for merging. I don't disagree but for that the API should be versioned and documented, of which this API is unfortunately neither. In the absence of versioning, a simple removal of field will break the whole chain of clients in a far away code, and we don't want that.

anbsky commented

2019-09-20 08:51:33 +02:00

(Migrated from github.com)

Also the user object path is hardcoded and I am not sure why. Maybe its a const for some other change?

Fixed.

> Also the user object path is hardcoded and I am not sure why. Maybe its a const for some other change? Fixed.

No reviewers

tiger5226

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbry.go#72

No description provided.