I have a Grails controller with multiple actions. For now all actions are available for user calls (I can access them from my browser), even the ones that should be called only from withing the g:include tag. I want to restrict access to such actions from the browser. I cannot mark action as protected because in this case I will not be able to include this action in a view for another controller.
Is there any practice how to encapsulate actions in such situations?
The way to “protect” actions from being accessible via a URL is to not provide a URL mapping to them. The default url mapping looks something like this…
class UrlMappings {
static mappings = {
"/$controller/$action?/$id?(.$format)?"{
constraints {
// apply constraints here
}
// ...
}
}
That “/$controller/$action?/$id?(.$format)?” mapping is convenient for simple crud apps and demos well but for any substantial app you should almost always remove that. Without it, only the actions you explicitly expose are accessible.
Related
Grails 3.0.1 here. I'm looking to accomplish a specific URL/controller structure. My app deploys at the root context (/), meaning locally it runs as http://localhost:8080, and non-locally as http://someserver.example.org.
I want everything under /app/* to be authenticated and considered to be part of the "core app" (requires login). Anything outside of that URL is considered to be a part of the public website (unauthenticated). However, I want /app/ itself to just be a placeholder of sorts; I do not want it to be a Grails controller. Hence:
http://localhost:8080/app may be configured (UrlMappings?) to bring up a login page
http://localhost:8080/app/<controller>/<action> follows typical Grails controller/action suit, and would invoke the correct controller action
Hence http://localhost:8080/app/order/create would be authenticated and, if logged in, invoke the OrderController#create action, which might render a createOrder.gsp.
I'm wondering what the Grails 3.x approach is to:
Allowing /app/ to exist, but not as a controller (like I said, perhaps just redirecting/mapping to a login page)
Allowing anything underneath /app/ to follow the controller/action paradigm
Thoughts on how to implement this?
Update
class UrlMappings {
static mappings = {
"/$controller/$action?/$id?(.$format)?"{
constraints {
// apply constraints here
}
}
"/app/$controller/$action?/$id?" {
???
}
"/"(view:"/index")
"500"(view:'/error')
"404"(view:'/notFound')
}
}
Grails has the possibility to declare namespaces for Controllers. With this, you can put all your controllers under the namespace 'app', which should result in exactly your second question. See docs for more details.
The security restriction then be accomplished with normal spring security settings (#Secured e.g).
I'm new to cakephp, I'm doing a web application in cakephp 2.3.5, my application has several controllers with corresponding models in each controller. I have actions with their respective views, and other actions that are simply no view functions that are used by other actions.
I have two questions:
One, of such actions is to remove an entity, is there any way that the user does not execute its actions through the browser by entering the URL (eg ... / estudiantes/delete/6)?, Meaning that only actions can launch web browsing.
Two, I have several user page belongs to a different role, of course there will be action in which a specific profile can not use and others who, for this I use the function "IsAuthorized" on each controller, controlling every action and seeing the user and the role it plays using the session, would it be right?
First question: yes, just change the delete action to protected or private and only other actions within your controller can access that. Or, if you're trying to use it with ajax or post, add this in the delete action
public function delete($id=null) {
if ($this->request->is('ajax') || $this->request->is('post'))
//do delete
else
//redirect or throw error or sad face
}
Second question: yes.
Or you could use plugins, like ACL.
Anybody who already have implemented something similar using Grails could tell me please which are the good pratices (if there are any) to create user profile URLs with the format "http://www.myservice.com/username", as in Facebook, Twitter, Linkedin?
I'm trying to implement it through the UrlMappings and appears to me I'll need to break with the code conventions, at least for the Controllers.
So, any suggestions are welcome, thanks.
UPDATE 1
When I mentioned my concern about breaking the code conventions, what I'm saying is that I want to show the user profile using this mapping, but I do have other objects in my application which I would like to access using the default mapping:
"/$controller/$action?/$id?"()
SOLUTION
Thanks to the great contributions I've received here, I've camed up with this solution, which solves my problem.
As was pointed out, to do this kind of mapping, I'll need to control more closely how my requests are handled. That means I'll need to tell to Grails which controllers I don't want to be mapped to the "username" rule.
Since that will be a very tedious task (because I have several controllers), I did this to automate it:
UrlMappings.groovy
static mappings = {
getGrailsApplication().controllerClasses.each{ controllerClass ->
"/${controllerClass.logicalPropertyName}/$action?/$id?"(controller: controllerClass.logicalPropertyName)
}
"/$username/$action?"(controller: "user", action: "profile")
}
...
}
And of course, I'll need to do something similar in my user registration process to avoid usernames to be equal to some controller name.
That's it, thank you all.
Assuming you have a UserController and you are going to map any domain.com/username to the show action of user controller, your url mapping could be something like this :
In my example, name will become a parameter in your params.
for further details refer to here
Hope this helps.
static mappings = {
"/$name"(controller: "user", action: "show")
...
}
Given your requirements, everything after http://yourdomain.com/ can be a username or one of your other controllers, which can have undesired effects depending on which url mapping is defined first (e.g. user controller vs nonuser controller). But most likely the nonuser controller list will be the smaller list, so you should place that first and filter against it, then treat all other url mappings as user mappings.
Here is an example:
static mapping = {
"/$controller/$action?/$id?" {
constraints {
controller inList: ['nonUserController1', 'nonUserController2',...]
}
}
//this should work for /username and /username/whateveraction
"/$username/$action?"(controller: 'user')
}
Some things to note here:
you need to place the non user controller url mapping first, since everything else after http://yourdomain.com/ may be a username - correct?
second you need to place a constraint to catch all the non user controllers, while ignore the user url mappings
also you need to prevent a user from signing up with a username that matches one of your non user controllers
I have some experience maintaining Grails apps; now creating a "task management" application as an exercise.
Apparently there is a view dichotomy of Groovy Server Pages versus Controller actions that render a view, as evidenced by this snippet from a URLMappings.groovy example:
static mappings = {
// ..
"/" (view:'/index')
"/login/$action?" (controller: 'login')
"/logout/$action?" (controller: 'logout')
"500" (view:'/error')
}
where user-facing URLs must be mapped to either views (GSPs) or controllers rendering a view, e.g.:
class LoginController {
/**
* Show the login page.
*/
def auth = {
// .. auth logic
String view = 'auth'
String postUrl = "${request.contextPath}${config.apf.filterProcessesUrl}"
render view: view, model: [postUrl: postUrl, rememberMeParameter: config.rememberMe.parameter]
}
}
From a design perspective, how do I choose which method to use? When do I create views with GSPs/taglibs like typical server pages outputting HTML, and when do I map a URL to a controller that renders through a delegate GSP? Can I combine both approaches? Have I oversimplified the options here?
To add to what hvgotcodes said, related to your question, the only time you'd want to map directly to a GSP view is when that view is effectively "static".
By static I mean that it isn't relying on the database or any real calculations for rendering the view. It can still be dynamic in that it relies on tag libraries for dealing with common elements, and things like the "Welcome user" text at the top of pages.
As soon as you want to deal with user-supplied input, looking up database information, manage more complicated URLs, or include calculations, you should be using a controller.
The end goal is that GSPs only contain visual and layout information, as well as the occasional static block of text. But you should always avoid mixing any logic in with the GSP, because it clutters the code and always leads to maintenance headaches later on.
Edit regarding Tag Libraries:
As I wrote below:
Tag libraries are for any logic that is connected to the view, like looping over elements, or toggling the visibility of something. Whenever you are tempted to put code directly into your GSP, it probably should be put in a tag library. Of course, there are always exceptions for one-offs.
So, if you have logic code in your view, that specifically relates to visual or layout content, that should be put in a tag library. A good example is the <sec:ifLoggedIn> tag from Spring Security Core, which can be used to toggle the visibility of an element if the user is logged in. This is much better than writing it manually like so:
<sec:ifLoggedIn>blah blah</sec:ifLoggedIn>
<g:if test="${session.user?.loggedIn}">blah blah</g:if>
Because it makes the purpose clearer (by its title), as well as abstracting the logic away, so if you later need to change the way something works, you only have to change it in one place.
tl;dr:
GSPs - Simplified "static" content
Tags - Reusable dynamic components specifically for visual or layout content
Controllers / GSPs - dynamic content
I don't think it's a dichotomy. GSPs and Controller actions (are intended to) work in tandem, the controller invoking services to load data in preparation for passing that data to the appropriate GSP.
The url mapping stuff is for if you want to break the Grails convention for urls, which is orthogonal to how loading data and displaying data (are supposed) to work.
The only time (IMHO) there is a dichotomy is when developers in a project code functionality inconsistently; i.e. it is certainly possible to give the appearance of a dichotomy.
Let's say we have a grails web application exposing several resources.
tags
urls
users
The application has a classical web-interface which the users interact with and some administration.
We want to expose the resources from the application to clients via a RESTful API and we don't want that part of the app to clutter up the controllers and code we already have.
So we came up with the following:
If the web interface offers host/app_path/url/[list|show|create] we want the REST API to be at /host/app_path/rest/url.
So we ended up with the following UrlMappings file:
class UrlMappings {
static mappings = {
"/$controller/$action?/$id?"{
}
/* adding new urls and listing them */
"/rest/url"{
controller = "urlRest"
action = [POST: "save", PUT: "save", GET: "list", DELETE:"error"]
}
/* accessing a single url */
"/rest/url/$id"{
controller = "urlRest"
action = [POST: "update", PUT: "update", GET: "show", DELETE: "delete"]
}
/* non-crud stuff on urls */
"/rest/url/$action?/$id?"{
controller = "urlRest"
}
"/"(view:"/index")
"500"(view:'/error')
}
}
The problem is, that this isn't exactly the most DRY thing here. It gets worse as we add more resources such as tags. They would translate to yet another three blocks of very similar code...
The non-crud functions will be things like searching with specific criterions and such...
We tried generating the mapping closures with a loop, but without success. Are we completely on the wrong track here?
I would recommend the following mapping:
"/rest/url/$id?"(resource:"urlRest")
Below is the HTTP method to action mapping that this would create for the urlRestController:
GET show
PUT update
POST save
DELETE delete
I see why you might want to map /rest/url POST to save and /rest/url/id PUT to update, but that goes against the meaning of those verbs. A PUT should be the only way to add a new url and POST the only way to update a url. Doing it the way you have laid out would work and might be the best way if your constraint is to keep your current controller code untouched. However, my guess is that you controller might already be coded to handle the default mappings just fine (update/delete give error if no id, show redirects to list if no id, etc.).