I have make rdoc to generate the documentation of my project but now i would like to make them accessible from application so allowed (logged in users) can access/view them from my site.
Thanks in advance.
Well, what type of application are you running? If it's something like MVC (or has a routing layer) you could probably specify some type of hook or serve them from a controller such that the path doc/<rdoc-files> was handled by a controller that would perform user-auth and then serve whatever static file the user is requesting.
You could also put everything into an IFrame that takes up the whole window (and really shouldn't be visible) and you could serve the IFrame server-side and include your authentication there.
There are really many ways in which you could prevent un-authorized users from accessing your documentation. It really just depends on what you are comfortable with.
Related
I have a GWT application that resides within a single web page, which I believe is fairly typical. I am in the process of securing it, and I need advice on choosing a proper approach. My ultimate intention is to check for presence of authenticated session on every gwtrpc server call.
In the past when dealing with servlet/JSP-based web application, I used filter and filter-mapping definitions in web.xml. And that worked like a charm considering that such applications usually consisted of many web pages, and redirection to a login page went right along with it. But in case of GWT and its often-used single screen nature, I feel that overriding RemoteServiceServlet's processPost() function may be a better approach. My intention would be to check for presence of an existing session, and then throw an appropriate exception if needed. The client would then react accordingly (i.e. login popup, etc) by determining the course of action based on whatever exception is thrown back to it.
I am aware of other existing solutions such as Spring security, but I would really like to hear opinions on my idea. Thank you.
I don't think that you should check for an authenticated session yourself. Let the application container deal with that. Of course, in order to do that, you will need a login-config section and security constraints in your web.xml file.
A good way to secure specific parts of your application is to check (prior to the actual display of the screen) if the current user is allowed to. From your remote servlet you can call getThreadLocalRequest().getUserPrincipal() to get the actual user (null if not authenticated) and getThreadLocalRequest().isUserInRole("admin") to make the autorization.
Hope this is helpful for you !
I'm currently searching the best way for developing my next webapplication. I'm thinking about using Backbone.js and build a single page application. But I really can't imagine how to secure my app since nearly everything is done on client side. Of course I just could prevent the users from accessing my RESTful Api so they would not have access to my data. But all the view/model/collection/template js files are still accessible.
Or is there a known way to serve the js files with php (laravel), which would allow me to only serve the files I need for the respective user.
I just couldn't find a solution by searching the Web. But I just don't think that I am the lonely person who needs a clean and secure authentication method including different user rights.
Thank you in advance!
Your backend application will fetch data from a backend (= API), and probably send back some changes.
This code can't have "security holes / leaks" as long as your backend is secured.
If you are afraid of people stealing your code, you can always minify the JS (check grunt.js and almond.js for this)
To secure your backend you can make use of Laravel's auth class, and the auth filter as mentioned before.
Besides normal auth, you could implement roles, that you can assign to specific users, giving them more or less access to certain resources in your backend.
Here's the method I would try :
Separate the application in two parts.
One part - login via regular Laravel Auth on a separate page, and then when the user is logged in serve the single page app in a different view.
Wouldn't this work?
Web Services are no different than any other web application you build. At the end of the day you are exposing functionality to the client (which is also the attacker). It doesn't matter what the client is implemented in, if you expose dangerous functionality you will be hacked.
Have a session state, keep track of the user id and make sure that the user is only accessing resources they have been allowed to access.
I do not think that what JS/template files are exposed really matters. Essentially, you should only be allowing data interaction to authenticated users. Think of this as two separate applications.
The front-end application logs in, and a cookie is stored (or some other persistence is used).
The back-end application then uses the persistent authentication to validate every single user request for data, and every user action.
This way you don't have to worry about the security, the client can only fetch the data that the server allows it to, and, likewise, it can only interact with the data insofar as the server allows it. You shouldn't be relying on the client side for security anyway, even logged in, otherwise some malicious user could, conceivably, save all your frontend code and use it against you without authentication.
I have a demo to make in which first a secure session is created with domain (let's call it paranoids.com), and then a bunch of locally read html+javascript (my demo) want to use that secure session. We are using google-chrome, started with --disable-web-security and --allow-file-access-from-files, on a linux/openSuse platform.
Why do I need to do that? I need to scrape some pages from that domain and re-render them with an alternative renderer. We have absolutely no say with that other domain owner.
What's the best possible approach for this, without asking my poor breadgiver to go through technical hoops? Can my script access the JSESSIONID of the domain paranoids.com when run with some command line arguments? Or, is it just not possible, and must the user copy/paste the cookie manually?
Thanks for any ideas that help realize that goal.
I'm building my first backbone app, and though I'm doing my authentication server side, there are features that non-authenticated users are unable to use, but because they are in my asset path, and part of my backbone files, everything gets loaded.
Is there a way to load only the resources that a user is actually able to use?
I'm using Rails with cancan to manage this server-side.
You need to split the assets out in to separate groups: a group that can be used by anyone, and a group that can be used by authenticated users. Only send the code that the user is allowed to use, basically.
I wrote a post about doing this with asp.net mvc recently. the same idea applies to rails, though the use of the asset pipeline makes the implementation a bit different:
http://lostechies.com/derickbailey/2012/01/26/modularity-and-security-in-composite-javascript-apps/
The best way is to create a Base view with a property named requireLogin: true/false.
All other views should inherit this view and the views which need authentication you should set requireLogin:true, for all others this property should be false.
After this you should handle the authentication base of this property.
I'm investigating using Kohana for my next project. The site will consist of user registration (and hence user profiles) where users will have certain privileges. The site will also have an admin section where administrators can go to say block a user or delete a post or look at usage statistics for example. A good comparison site would be a multi-user blog, where each blogger depending on her/his permissions can post/edit/delete blogs...just as an example.
Firstly, I'm not sure about how to set up the controller/view structure in order to separate the admin section from the front facing site. I'm using Kohana 3, so I was thinking of a controller structure like so: application/classes/controller/front (front facing)...and application/classes/controller/admin (for administrative section).
Or I notice you may be able to use the Route class to set up routes, so I could set up an "admin" route. for example: www.example.com/admin will lead to the admin logon screen.
www.example.com ---> front controller.
As well, can I somehow separate the "Admin" views and controllers from the "front facing" views and controllers like divide them up based on folder structure? Any help is very much appreciated.
Thank you.
You could have a separate application folder for the admin and front-end:
application
classes
controller
model
views
admin_application
classes
controller
model
views
This approach would allow you to customise each bootstrap environment individually, and separates the various files nicely. However, due to this separation you will need to structure shared code as modules, to allow the functionality to be shared across the two apps. You could just duplicate the code of course, but that would wrong now, wouldn't it! ;)
Another approach would be to have admin subfolders within each folder of a single application:
application
classes
controller
admin
model
admin
views
admin
This approach leaves files a little more intermixed, and might make things harder to maintain (depending on your perspective), but it's certainly easier to implement. One advantage of this approach is that you can create a /public_html/admin folder and protect it using .htaccess (you'll need to add a copy of the normal index.php file too). Then whenever any http://yourdomain.com/admin requests are made, the .htaccess file will kick-in and protect your admin application at the webserver level. Plus, the request will automatically route to the /admin subfolders within the various folders, so you've also got less work to do when it comes to routing.
Both situations would use Kohana's (awesome) routing mechanisms to handle which requests went where, and each is as secure as the other from an application access point of view. I've assumed you're using KO3 by the way...
EDIT
Actually, you are able to .htaccess protect the admin app if you use the first method too. You'd just need to adapt the /admin/index.php file to point to the admin app.
My approach would be similar to the first one but then for each module I would create a admin controller and a frontend controller - All my admin controllers would inherit from an abstract admin controller that would have the authentication in the before method - or something like this.