How to persist data in a command-line application? - node.js

I want to build a command-line application using Go or Node.js. I want to make it multiuser, so a login feature is needed. I can implement the login feature but I don't understand where should I store the user data which can be fetched any moment at runtime.
The user data is needed to check if a user is logged in or not if he is logged in which user it is.
Need help with a method to store user data to check logged in status
Edit:
I had thought of this- If the config file is present that the user is logged in else not. Then I realized that if one tampers the file, the whole point of login feature will get invalid. I am guessing there must be a better way to do it, which I am trying to know by asking here

Many cli utilities opt to store their configuration as a plain text file on the user's home directory.
You can use any of the available configuration formats such as JSON, TOML, etc.
Although it's good to mention that this is not a secure way of storing data and if users should not be able to see others information in any way this is not the preferred way.

Related

password token to view pdf

I know that the title can be better, but I don't know how to define my problem.
my problem is the next, I'm not sure if it's possible to do, but i suppose that it is.
I have some .pdf online and i want to protect them for third people.
My idea, instead of assign a password and show an input like this:
I want to send the password (or token) in the path. something like
file.pdf?tpw=aaaa-bbb-dddd
Is it possible? I'm using C# to create the pdf.
edit: the case
I have an application which create a folder with some pdf, those pdf can be uploaded or created here with a form. (this part works)
All this documents are stored in internet (global access) then I want to prevent that 3rd people or search engines (I'm reading about this, it doesn't looks like a big problem)
Then here is the problem, i want to some users can access to some pdf, for example
user K can access to pdf 33
user j can access to pdf 54
but not k to 54, etc.
my idea is send to the user (they should access throw the link) something like "https://domain.com/pdf/33.pdf?password=222222" and without this password cant access.
if is not possible to do it, i can create an "intermediate page" to put the links there.
and send the url like "http://domain.com/pdf/view.chtml?id=33&password=222222"
edit: and prevent the access if they type https://domain.com/pdf/33.pdf
EDIT 2: SOLUTION (at least per now)
store into the database for each file
- filename - user(in md5) - token (in sha1)
send to the user a link like www.domain.com/api/showpdf.chtml?user=XXXXX&token=KKKKKKKKKKKKKKK
When the user clicks on that just check in the database by the user and the token if any file exist, if is this case show the file.
To solve the problem with the direct access, we are going to put the files out of "localhost" folders
Thanks for all.
I don't think it is a good idea to GET your passwords, they will be visible, the password should only be sent once, start a user session in the server, which will then create a temporary ticket for the user, and this ticket should be sent on each request via POST.
Anyway, you'll need to use a database and store users, passwords, files, and per-file permissions for each user, you could use a file, but it's never a good idea to store the passwords in plain text. I guess you already have a database running, you'll only need to add a files and a per-file permissions table to it.
Also, you should never keep the real password in the database either, but just a checksum of it (SHA-1, or similar)

Protect remote resources when served with nodejs

This is more of an architecture question involving nodejs as implementation.
I have on a folder not exposed by the webserver files that I want to offer to the user.
The way nodejs should expose the resource to the end user is via a one shot link, that once is consumed is no longer available.
The user through the entire experience should never know the real location of the file.
I'm sure this is a common architecture pattern, but I have never implemented something similar.
Looking at scalability, the resource shouldn't be copy either on HD or RAM, and if possible the solution should not relay on a DB token tracking system.
I don't necessary need a code implementation, but a detail explanation on how I should implement it
Thank you so much
Give user a cookie
Create a temporary association (in db) between cookie and a generated ID for the user (or the hash of it, if you want to be fancy)
Give user the ID
When user requests resource by ID:
Test to see if the ID (or its hash, if you want to be fancy) is in the DB
If it is, give the user the resource and destroy the association between the user and the resource ID
There's a db token tracking system. Hey, that's the only way.
One way to avoid depending on a DB, would be to maybe create a symbolic link in the filesystem (based on the token), that would be removed after a request for it. Would not work satisfactory on windows though.
Example (psuedo):
Create token (guid, or similar)
symlink guid -> actual file
once request is completed, remove symlink
However, I don't think there is a reliable way of knowing if the file was successfully downloaded, so you better prepare for that. Some sort of pingback when the file was completely downloaded is probably the most reliable way that I can think of right now.
For scalability, make sure that the symlink is on a shared file system. Clustered node.js instances on the same server, will be fine though.
If this needs to be restricted to an authenticated user, you could combine the guid with your auth token, and prepend/append it before looking for a file.

Node.js user system

I'm currently working on a web application which deals with multiple users. Whilst it currently works, it relies on some real bad practises which I'll outline in a minute.
We're using MySQL as the database system, since we're updating our current application, we want to ensure everything is backwards compatible. Otherwise I'd look at MongoDB etc.
Our users are stored in a table aptly named login. This contains their username, email, hashed password etc and a field which contains a JSON encoded object of their preferences. There is no real reason for doing this over using a meta table.
So the bad practises:
We're storing the entire users login row, excluding their password (although this is an internal-only app) in a cookie. It's JSON encoded.
Once the user logs in we have a secure HTTP cookie, readable only via Node.js for their username and their password so that we can continue to keep the user logged in automatically.
We have a app.get('*') route which constantly ensures that the user has their three cookies and updates their acc cookie with new preferences. This means that every time the user switches page or accesses a new AJAX item (all under the same routes) they have an updated cookie.
Every time a user performs an action we do this to get their user id: JSON.parse(res.cookies.acc).agent_id yuck!
Now, each user is able to perform actions to certain elements on the page, this effects everyone as the application is internal and anybody can work on the data inside of it.
I know what I want to achieve and how it should be done in say PHP, but I can't figure out the most effective way in Node.js.
I've started creating a User module which would allow us to get the user who performed the action and neatly update their preferences etc. You can see this here bearing in mind that it's a WIP. The issue I'm having with the module is that it doesn't have access to the users cookies, since it's not "a part of" Express. Which explains the last bad practise.
What would be the best way to handle such a system and remain bad-practise free?
I doubt it meets all of your requirements but its worth checking out out Drywall; A website and user system for Node.js
Hopefully it (or parts of it) could be helpful to you.
http://jedireza.github.io/drywall/

sfGuard token login for wkhtmltopdf

wkhtmltopdf allows to make a screenshot of a browser view with a webkit browser.
I have a Symfony 1.4 application that requires login, which I would like to use wkhtmltopdf to create a "print this page" function.
How can I securely facilitate this. I'm thinking of creating a one-off token on each screen for the print button that allows wkhtmltopdf to login without using the password of the user.
Any suggestions for how to structure this?
We'vbe come to the conclusion to use the built in "keep me logged in" functionality for this problem.
Would you consider a different printing framework ?
What about jquery plugin (e.g. https://github.com/ianoxley/jqueryprintpage#readme) ?
That way you won't have to allow access to the restricted area from outside the session.
If you still want to use wkhtmltopdf, you can easily create an action that receives a url and a user_id and creates a unique token, I might save this token in your DB or in a Key-Value cache (depends what is your system architecture). I wouldn't create the unique token in advance, I think its better creating it on demand (When your user is asking a print).
You have couple of options in order to enable printing in secured actions,
1) Create a custom security filter. In the filter, in addition to authenticated request, you have to allow requests that contain "token" parameter with right combination of url and user
2) Change the action to unsecured. If you don't want the change the security filter, you would have to change each action to "unsecured" and create a function that verifies if either the request is authenticated or it has a proper token parameter.
It would be smart to remove each token after you used it once to make it even harder to guess a token.
In addition you might want to create a periodic worker that clears old tokens that were never in use.
Even though you already decided on an approach, I would still like to add one more alternate option that might help others viewing this issue.
Another alternate route might be to grab the current source of the page being viewed and post that into your printer backend using something like
$.post("/printer", document.documentElement.outerHTML);
This way you can also preprocess the HTML in an easy way. Your backed could first store the HTML and then parse it to for example convert images or perhaps remove some parts of the page that will not be used when printing.

Displaying PDF to user

We're providing a web form whereby users fill in their personal information; some of it is sensitive information (SSN, Birthday, etc). Upon user submission, the data is prefilled into a PDF which is then made available via a link.
We are creating the PDF in a folder that has write access on the website.
How can we safely create and add PDFs in this folder, with whatever naming scheme (use a GUID?), such that another user cannot guess/spoof the PDF file location, type this in the URL and access another person's PDF?
Maybe the PDF folder has rights only specific to the user, but that may be a different question on how that is accomplished. (The number of users is unknown, as this will be open to public).
Any thoughts on this? In a nut shell, we need to allow the user to view a PDF of the data they just entered while preventing more-savvy users to figure out the location of PDF files, allowing access to other files.
Thanks!
trying to obfuscate the path to a file isn't really making it secure. I would find a way to email or another way to fetch it for the user instead of allowing access to an open directory.
Make the web app fetch the file for the user instead of relying on web server open folder permissions.
just keep in mind obfuscation isn't really security.
If it's really just for the moment, create a completely random file (20384058532045850.pdf) in a temporary directory, serve that to the user immediately and remove it after a certain period of time.
Whether your web app has write rights on that directory or not (I assume you are talking about chmod user rights) is not important, it can't be breached trough the web server and I don't see a problem in revealing the directory path per se - you have to reveal something in giving the user a URL to download. If your PDF names are random enough, there is practically no risk of somebody being able to guess the name of another PDF file in the same directory.
As the PDF contains sensitive data: Don't forget to turn off caching to prevent a local copy of the PDF being saved on the client's browser cache.
I don't know for sure whether turning off caching through the appropriate headers is enough to prevent local caching in all browsers. You might have to look into that.
For the purpose of pdf's, would it not be better (I know I will get flamed for this) to store the actual pdf into the database as a BLOB, which would be on the back-end of the website in question?
There will be no reference to the URL anywhere nor will there be a specific path highlighted in any links on that form.
Hope this helps,
Best regards,
Tom.
The simplest way is to proxy the file through your application (fpassthru() in php for example), this allows you to use what ever access control/identification system you already use for the dynamic content.
If you don't have any means of identifying your users and restricting access, and assuming your platform has a secure session mechanism, you can protect the file by storing the filename in the user's session and then returning that file (and only that file) to the user when requested. This should mean that an attacker would have to spoof a session to access the file so this should be as secure as your session mechanism is.

Resources