enable portable use instead of installing it for the user

[kkarhan]

whilst installing wsend into $HOME/.wsend for a user is convenient, it should be possible to at least run it as a portable executeable that doesn't install itself locally [or if unavoidable, into a folder under ./.wsend or ./wsend and not $HOME/.wsend.

I understand why there might be a need to do so [i.e. to keep the "id" file which includes the API key used to identify installations - both anonymous and registered.

In case this seems exploitable for malicious use-cases, I'd be happy if this features would require not only --portable or similar flag, but also a --login flag.

I could even accept if this functionality would be limited to paying customers.

[abemassry]

this can be a very simple script like:

#!/bin/bash
id=$(curl -s -X POST -d "email=email@example.com" -d "password=passwd" https://wsend.net/login_cli)
curl -F "uid=$id" -F "filehandle=@$1" https://wsend.net/upload_cli

if you were to save this somewhere and chmod +x it would probably work ok the problem is you'd have to log in every time so you might want to do some checking like this

#!/bin/bash
if [[ ! -e "./wsend_id" ]]; then
  read -p "email: " entered_email
  stty -echo
  read -p "Password: " passw; echo
  stty echo
  id=$(curl -s -X POST -d "email=$entered_email" -d "password=$passw" https://wsend.net/login_cli)
  echo "$id" > ./wsend_id
fi
uid=$(cat ./wsend_id)
curl -F "uid=$uid" -F "filehandle=@$1" https://wsend.net/upload_cli

if you chmod +x ed that it would work you could save it to something like wsend and then run:

./wsend file.txt

we can develop it further if its something you think you might like

[kkarhan]

The workaround using curl -F is something I have used in the past with other sites, which officially support this and showcased it exemplary in this code.

That being said that I only use wsend for bona-fide purposes and said code is a learning example...

My suggestion would be to enable login via some sort of "API Key" instead of the account credentials in plaintext. Said API key would be easier to replace and could also enable to setup retention limits [i.e. 24 hours or 1 download - whichever happens first] on the webinterface...

For paying/premium users, multiple API keys with different retention settings could be enabled.

How does that sound?

[abemassry]

do you mean API keys have retention settings or the files have retention settings, because we have a --ttl option for files

[kkarhan]

Not solely for TTL settings, but rather as replacement for plaintext logins so that one can't take control over an account just by finding those logins in .bash_history

[abemassry]

I tested this by trying a login in bash, if done in an interactive terminal the command wsend --login is the only thing that shows up in the .bash_history In the scrollback of the terminal the password is hidden, but the email address is shown. After logging in, in the terminal a ~/.wsend/.id file is produced which can be used like an API key, but you're correct in that it doesn't expire

[abemassry]

I've started working on this issue again, how were you envisioning this part to work:

Said API key would be easier to replace and could also enable to setup retention limits [i.e. 24 hours or 1 download - whichever happens first] on the webinterface...

for the 1 download, would an API token be used for a download? currently downloading files doesn't check an api token, they are only used to upload files or pull other account specific information

[abemassry]

This feature is done and has been implemented for paying users, like you have suggested. Let me know what you think, Thanks!

[abemassry]

[kkarhan]

Seems like a good option to do so if someone wants to use wsend to automate stuff. Paywall is a sadly yet necessary means to avoid abuse.

For everyone else, this workaround of yours should be sufficient.

Thanks for implementing the feature.