Add an option also to request a secret#11
Conversation
| 'rid secret stored desc': 'The requested secret can now be revealed on the other side.', | ||
| 'secret': 'Secret', | ||
| 'share new secret': 'Share a new secret', | ||
| 'share new file': 'Share a new file', |
There was a problem hiding this comment.
I am not sure, but I did not find the link check for the 7 days validity (two lines down)?! Where is it? Or did you forget to implement it?
Not really sure why this not worked before...
work not finished yet....
This should be correct ;)
|
Sorry for the super late response. My first gut feeling would be: That is out of scope for this program. What is the actual pain point here? 🤔 Is getting the (long) link from your secure system to the gaming system the issue, because that’s cumbersome? 🤔 |
I would say: yes. Transfering the link to a system which has limited receiving capabilities. This could be an insecure system, a limited system like an E-Book-Reader or any other system where communication in one way is much more difficult than the other way around. For an other maybe more relevant use case, please ask @sschmachtel and other technical consultants. It might also help transfering secrets from customers. From practical experience (I host my own system with this feature implemented): |
| (1_000_000_000, 'GB'), | ||
| (1_000_000, 'MB'), | ||
| (1_000, 'kB'), | ||
| (1_000_000_000, 'GB'), |
| def cleanup_rid_infos(): | ||
| now = time() | ||
| for f in listdir(REQUEST_INFO): | ||
| if stat(REQUEST_INFO / f).st_mtime < now - 7 * 24 * 60 * 60: |
There was a problem hiding this comment.
Won't the cron job mentioned in the README already clean that up as well?
The program does not automatically remove secrets which have never been retrieved. You might want to install a cron job on your system to remove old directories in
$FLUESTERFIX_DATAbased on their mtime.
If not, we should do it this way. Iterating over the whole REQUEST_INFO dir for every request of create_rid() seems wasteful.
There was a problem hiding this comment.
Ah OK, I did not recognize the cronjob thing. Then it seems to me the cronjob might be right.
| scheme = request.headers.get('x-forwarded-proto', 'http') | ||
| host = request.headers.get('x-forwarded-host', request.headers['host']) | ||
|
|
||
| request_link = f'{scheme}://{host}/?rid={rid}' |
There was a problem hiding this comment.
please use url_for() with external=True for that instead of constructing the URL manually
| btn_js = ( | ||
| 'id="button" ' | ||
| 'onclick="' | ||
| 'id="button" ' |
There was a problem hiding this comment.
We shold not use weird unreadable abbreviations. Maybe rename to localize.py or translation.py.
| from qrcode.image.svg import SvgPathImage | ||
|
|
||
| enable_qrcode = bool(environ.get('FLUESTERFIX_ENABLE_QR')) | ||
| except ImportError: |
There was a problem hiding this comment.
I don't like the concept of optional dependencies. Either make this a full dependency, or remove it. Either is fine for me.
(If we do QR codes, then we should also add a QR code to the "send this link to the other person" page)
There was a problem hiding this comment.
What is the reason for your dislikings?
I did this, because I am aware that there are different kind of people: For some it is important to have as little dependencies as possible, for others the user experience is more important.
|
FTR, I’d like to:
Let’s not rush things, please. 🙂 |
4 participants
In my use case I often have a relatively insecure system (like my Gaming Windows). I do not want to insert any security relevant information there like logins. But sometimes a want to get information from elsewhere to this system.
The idea is now that I simply navigate to fluesterfix on this system and ask for a secret. Then I transfer the request id manually or by QR Code to the system where I have the desired information. I can now put this information into fluesterfix and connect the secret url with the request ID. I switch back to the insecure system and retrieve the secret information.
This pull requests implements the functionality as described.
Please review and add your comments and change whishes :)
In this implementation this is a "hidden" feature and not accessable through the normal interface. You're welcome for good ideas how to integrate this :)
Also the QR-Code thing is not listed in the requirements. Maybe we want it as optional-requirement?
What do you think? Do you want to integrate this into the main branch or do you think the use case should be handled different/elsewhere, ...