I am working on a small project where my clients will have a control panel with which they can (obviously) control their gameservers. What bothers me is them sending the request to START/STOP the server. I tend to give the buttons an onclick function that makes a call using ajax, but I don't know if this is the best way to do this.
Right now I pass the users ID and the server's ID and then perform the operation he had requested.
It seems to me that there must be a better way, but I don't see it yet.
P.S. Currently the REST API for server control doesn't need any authentication. Still not sure how I could implement this without passing their information too much.
Related
I just learnt one can manipulate the frontend code of a website from the developer tools that comes with some browsers. Now, my question is that if someone can manipulate my js, HTML and CSS codes to suitable needs, and was able to send a request to my webserver, will the server receive and process the request as authenticated request. Let me site a suitable example:
Let's say I created a form that uses ajax to retrieve some information from my webserver, in the form I have a hidden input that contains numbers which determine the information that will be displayed (e.g. 1 should display information for level 1 users, 2 should display information for level 2 users). The default value of the hidden input is 1, now if the user (level 1) is able to tweak the frontend code and set the value to 2 before sending, will he receive the information meant for level 2.
If this is possible, how can I prevent such thing from happening, or what is the standard procedure for handling situations like this?
The typical rules in this case are:
Validate
Validate
Validate
Do not trust the client exclusively to tell you whether they have the permission or not. You should have the information to determine that on the server side, use it.
Validate client side requests, and make sure the user that is requesting an action has the actually has permissions to do so, and that the data they are sending is valid.
Sure, you can have client side validation for a good UX experience, but always backstop it with server side validation, authentication and authorization.
The best way to prevent your example scenario is: Don't send the client side data they aren't supposed to see and then rely on the client to hide it. If the user isn't supposed to see it, don't send it.
Im using GWT, GAE to make a web app.
I looked at a bunch of tutorials regarding implementing a login system but most of those tutorials implement it so it's mandatory to login to access the web app. How would I go about making it so that anyone can access the app but if they want to use account specific functionality, they they have the option of signing up for an account.
There are two parts to it.
First, in your client code you check if a user is logged in. If so, you allow access to the "closed" parts of the app. If not, you show a link/button to login and hide tabs/views that are accessible to authorized users.
Second, in your server code you specify which requests do not require authentication and which do require it. This is necessary if a user somehow figures out how to send a request without using your client code.
For example, in my code some requests have checkSession() called at the very beginning. If no authentication object is found for this user in session, this method throws LoginException to the client. If the authentication object is present, the request continues to execute normally and returns requested data to the client.
Further to Andrei's answer, if you want a framework to manage the sessions for you, you can use GWT-Platform, which has an excellent Gatekeeper feature.
I use it for mine and I have a LoggedInGatekeeper class. Simply add #UseGatekeeper(LoggedInGatekeeper.class) to the constructor of each presenter proxy and it checks if the user is logged in. If you want anyone to be able to access that page simply annotate with #NoGatekeeper. Easy!
It takes a bit of setting up but it's a great MVP framework. There are maven archetypes and samples etc.
Hope this helps.
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.
I am using Sencha Touch for some weeks now, and I plan to add to my webapp, a form with which users can contribute with informations. I was wondering of means of securing this form, since it will directly post entered data through an Ajax call to my server. It will not be too difficult for someone to sniff http traffic and write some script that would kill my database server sending data to my submit server side action.
I was wondering about using recaptcha, but I cannot see how to implement it or neither if someone has tried it. I am open for any other form of security that could be easily implemented in the context of sencha touch
Thx
Create some simple form of captcha if you want. Like addition of two numbers etc.
You wont prevent sniffing http traffic using a captcha, use ssl, if you send your requests using https no one can sniff your trafic.
But even that cannot prevent someone sending a crafted request to your sever trying to exploit it, since they can tell by looking at your client code what is the server expecting.
You can try to obfuscate your client code, but that wont help much either.
The only way to prevent it is by validating the requests on the server side and invalidate all the requests that can potentially harm your system.
I'm sure there must be a simple answer for this but I can't figure it out -
I have a Silverlight 4 OOB application that requires a login screen/security. The View shows a LoginView (Username/pw) which then passes the details to a WCF service and checks it against a database. It will return a result to the client to say if their details were valid or not. This part works fine.
Where I need some guidance is the best way of storing the fact that the user is logged on/authenticated for the current Silverlight session.
It's OOB so we can't use any web cookies/session stuff as far as I know. I assume we have to store some sort of Identity in the thread but I need some pointers please.
The other caveat is that I would like to secure all other pages to check if the user is authenticated and redirect to the login screen if not. I use the Navigation framework so I have a Frame - this may make it easier...
Any tips or pointers appreciated - I just need some ideas to get started please.
Just store the fact that the user is authenticated anywhere you like - I tend to like the Application object since it's an app-wide setting, but you can stick your "IsAuthenticaed" and/or "Roles" properties anywhere, really.
Take a look at WCF RIA Services - even if you don't want to use their solution, you can take a look at the generated authentication code it makes and see a good real-world example of how this can all work.
As for redirecting if the user is not logged in, I suggest using an INavigationContentLoader on your Frame, which can implement this logic in a central location. See these two excellent posts by David Poll on the subject of INavigationContentLoader and authentication/authorization:
http://www.davidpoll.com/2010/01/01/opening-up-silverlight-4-navigation-authenticationauthorization-in-an-inavigationcontentloader/
http://www.davidpoll.com/2010/05/10/common-navigation-ui-and-authorization-driven-sitemaps/