I'm working on a small marketing project with Zend Framework, the backoffice of the project is currently made of two controller: a campaign controller and a minisite controller.
The user create a campaign with a form, then he have to create a minisite with a second form linked to this campaign, so i need to get the campaign and the user id when saving the data of the minisite.
What is the best practice and why? should i pass those variables in a session object? or should i pass those variables through a route like :
/backoffice/minisite/create/:userid/:campaign/
Edit: users are logged and authenticated when creating campaigns
Assuming users have to be logged in to do this, you could store the user information you need in a Zend_Auth identity
If not, you could store the data in a normal session var with Zend_Session or redirect to with the route. Either option is good, so it's up to you to pick the one which best suits you and your application.
For passinf information between two controller the best way is to use session to store the values globally . :-)
I'm pretty sure users need to have an account to do these things. If yes, there campaigns and minisites will be associated with them in some way. I'd store and retrieve these things from some form of database.
If you're not having authenticated users and you really just need to pass two variables to another action, use url parameters but be aware of the fact that users can mess with them and a lot of unexpected stuff can happen. Storing in the session is harder to manipulate in that way.
So, if no authentication is involved and the site is public, use the session, otherwise use neither but use storage.
I would use the route option, as you suggest. Using sessions is going to end up being very difficult to test, debug, extend in the future etc.
Related
So I have a platform that works like this: Users can create accounts by logging in with their Google (I USE AUTH0) and then they can create "Projects" which contain lots of other unimportant stuff regarding my current problem (like todo lists, ability to upload files etc; they can also Edit the project by changing some of it's attributes like name, description, theme and so on). There is a home page where everyone can see each other's projects and access them (but not upload files, change the tasks in the to do lists; this is possible only by the person that owns it).
By using a tool like Burp, people can see the request made from frontend to backend, for example when accessing one of the projects, and modify it on the fly.
This is what it looks like inside Burp when they access one of the projects:
As you can see there is a Get request to /projects/idOfTheProject; they can replace the GET with DELETE for example and they will successfully delete it; they can also see what is sent to the backend when a project is edited (name changed, description, thumbnail picture etc) and change anything they want about it.
How should I prevent this?
What I've looked at so far:
a. JWT - Probably the best fitting for my situation, but required the most work to be done (as I already have my platform almost finished with no such a security measure implemented yet, so I may need to rewrite a lot of things in both backend and frontend)
b. Sending the user's id that initiated the action as well to the backend and verify if it has the necessary privileges - the worst solution as users can access each other's profile and see the id, then just change another field in the request's JSON
c. Have a sort of token for each user and send that instead of the user's id - in this way somebody can't get your token by just looking at the communication between frontend and backend (only if it is using YOUR account). That token should be taken maybe somewhere from the auth0 when they create their account? If they provide something like that; or I can just create it myself and store it alongside the other user variables. You would still see the requests in plain text but even if you modified something you would still have to "guess" the owner's token, which will be impossible.
For frontend I use NextJS and for backend Flask.
Thank you in advance!
The TL;DR is that you don’t. A determined user will always be able to see what requests are being sent out by the code running on their computer and over their network. What you are describing when asking how to prevent people from “sniffing” these requests is security through obscurity, which isn’t actually secure at all.
What you should do instead is have an authorization system on your backend which will check if the current user can perform a given action on a given resource. For example, verifying that a user is an administrator before allowing them to delete a blog post, or making sure that the current user is on the same account as another user before allowing the current user to see details about the other user.
I don't see an easy way to grant permissions to another user. It seems to be quite convoluted at the moment, and I wonder if I'm missing something obvious.
Say I want to invite another user to share a Realm. First I would have to ask the other user for their identification, then I would create the permission object, and then finally I would give the other user the address of my realm.
It would be great if I could share some sort of permission token via text message and let the new user register themselves. I suppose I could do that if I created another "User" which represented the shared group, and merely share this abstract user's credentials. It feels a bit hacky that way, but it seems easier to do.
I was hoping the demo application of the shared drawing environment would hold a clue, but after looking at the source code, it turns out both devices are logged in as the same user.
Am I missing something? Given the demo Draw application, how would one user practically invite a second user to join in their shared drawing environment? It seems like there would have to be a whole set of convoluted permissions and url/identification sharing handshakes.
Thanks for asking the question! Today, you will need to create a shared Realm that all users would input their user IDs into and have access to. This way any user can look up an ID and share access to another Realm.
We realize the limitations and are working on offering a number of improvements. The first is pretty close to what you describe, called a PermissionOffer object where you can inform the Realm Object Server you want to grant access to another user for a given Realm(s). The server will then provide a token you can share via any means with the other user. That user can then use the token to create a PermissionOfferResponse object and accept the access grant. This is coming soon, so stay tuned!
Later, we plan to offer a way to lookup user IDs so you don't have to replicate all of them in a shared Realm (see this issue).
I am building a web-app with Meteor and i am using the Meteor Accounts-password package and accounts-facebook package to make login easy. The user has some information tied to them like email & password, but i want to tie more information to them after the account has been created.
I know of two ways that i could do that and i was wondering how i should do it, since i can't seem to find any information about it on the internet.
Option 1:
I add all the additional information (like username, displayname and other stuff) inside the Meteor.user.profile object. This seems to be a bad solution since users by default have access to everything in the profile object and i have to manually deny them access.
Option 2:
I create a new collection, Profile-information, and store all additional data about the user and then tie it to the meteor.user object via some shared key. This also seems like a bad solution since i have to split my data like in SQL and not have all the advantages of embedded documents in mongodb.
This has been my thought process so far and i am at a loss of how to continue.
Which option seems to be the best way, or is there an option 3 that would work better?
Thanks in advance.
Thanks to #forallepsilon i found out that you could write any data to the user object you want. I previously though that the user object was locked, and you could only store additional data in the profile field.
I will store the additional data i have about the user inside the Meteor.user object by just creating additional fields.
It seems that basic functionality such as user login, can not be done in simple manner: to have username and password field in form on client and based on that to create store.readPathAccess model access rights. Also, how to check if user is logged in to implement access rights on routes?
Based on examples and (poor) DerbyJS documentation, if I understood it correctly, you have to implement login in server module (lib/server/*) because:
store.readPathAccess must be used in server side
you want to store data in model session (which can be read only on server side)
But many questions arise:
if it has to be done on server side, how to get and store client form data on server side without having problem with second item below on the list (I have done it with manually submitting data to server-only route, but can not then save it in model with local key because I have to redirect to client route after that and local model data is lost)
how to read later that data if it must be stored in session?
even if the store access rights for model is managed, how to check if this specific user is logged in when in client routes?
I'm quite confused at the moment... liked Derby principles, but this authentication problems are playing with my nerves seriously.
I know I may not be quite clear, but there are many points to go in details and if anyone can help I'll gladly give more required info.
Thank you,
Eddie
I found this library today called derby-auth.
It uses passport for signing in and has a good example using a simple register and login form.
What it does is to set some routes on the server for logging the user, and a middleware to tell the client if it's logged or not.
It does have some bugs (a few callback calls missing that break some things), so i wrote my own based on that, but must clean a lot of things before uploading anywhere.
i'd be glad to send it to you if you want to, though.
The most current library is https://github.com/derbyparty/derby-login
It has been updated pretty regularly and works with derbyjs 0.6
Ive got a asp.net mvc site that works with ASP.net Authentication. I have a UserInformation table which stores extra information on each user aswell. On pretty much every page i am calling to the database to pull the UserInformation record for the current user at least once.
Im thinking all these repeated data calls for the same information has to be overkill. Is there anyway i can cut these down? Caching? Storing the userinformation record for future use etc etc?
Im sure im not the first person to come across this issue, so i didnt want to reinvent the wheel.
Thanks in advance
You could use a custom IIdentity and IPrincipal. Here's a nice article describing how to achieve this (the interesting part is happening in the btnAuthenticate_Click method which in an ASP.NE MVC application would be the authenticate controller action, here is emitted the authentication ticket with custom data). In this example the idea is that the authentication ticket is manually created and the userData property is used to store additional information. This might not be appropriate for your case if you have lots of data because this is stored in a cookie. But instead of using the userData you could store it somewhere else like Session or Cache. You could also write a custom [Authorize] attribute to deal with the custom principal (the part that corresponds to the Application_AuthenticateRequest method in the article should go in this custom authorization filter in order to reconstruct the user back).