Background
laravel currently allows you to easily define views for specific HTTP status code responses. For example, an HTTP status code of 404 will display the resources/views/errors/404.blade.php view automatically if it exists. it works the same for other codes like 500 errors.
Problem
All of the routes on my site are processed through controllers, all of which extend a base Controller. This base controller sometimes initializes the user, sets the current timezone, and other random stuff. The master template often relies on these variables. For example, if a user is logged in, the Controller figures that out and passes that user to the view. My master template looks for that user, and shows certain functionality if present. When a 404 is hit, I want to still be able to show the user specific menus, and continue using that 404 view.
Question
I submitted an issue on Github to see if we could route HTTP exceptions through controllers, but they did not agree with the proposal. So now I'm looking to see if there is a way to render a controller method when I catch an HTTP exception. I do not want to simply redirect to the appropriate route, but rather catch the exception and render the controller method.
I don't know enough about the internals of the routing, so I'm curious, is this possible? And if so, how do I do it?
Thanks!
It's definitely possible - look into the ExceptionHandler (under app\Exceptions), or look at implementing some Middleware to catch unknown routes.
Alternatively you can also extend the 404 view from your base template, save data in the session to present on the view or even call a ->back() on the 404 with a flash error.
Related
I have a page html let's call it abc.html
There are AngularJS fields embedded in it.
I am now writing a GET and POST in scala which routes the fuzzy search arguments to the proper page on the server.
I am trying to understand the sequence in which things occur in order to implement a GET/POST requests (written in scala) which would happen when someone makes a search on the search bar on the abc.html page, and which would return elements from the database
Is it abc.html (search) --> http GET request --> backend ( AngularJS) --> Database?
In this case this would mean my http post or get request would pass in the html data model elements which would in turn hit the backend AngularJS controller page which in turn would hit the database, and the return ride would send the database results via an http request to the page?
Do I need to explicitly define my GET in terms of angular fields and the database model?
thanks
HTTP uses request-response pairs. This means you don't have to make another request to return anything to the client, you just need to write the proper response. Other than that, your idea is fundamentally right. The process would look something like this:
Type something into the search form on your HTML page
Submit the search form to your backend. This creates a GET or POST request depending on your form element's method attribute.
(At this point the browser is awaiting a response)
As the request reaches the server, your backend code can capture its data and make a query to your database.
(At this point the server is awaiting data from the database)
The database returns its results, your backend code is free to format it into a response to the client's original request.
The client receives the response and you can use your frontend code to display it to the user.
I'm doing a web app based on original MEAN.js framework. When I want to request local json test file using $http.get() method in my AngularJS file, it returned my index html content.Is it a routing problem? I didnot change the original mean.js routing code(https://github.com/meanjs/mean), just added a $http.get() method in home.client.controller.js file. Can anyone help me with this? Thanks!
That is most likely happening, because you didn't define an endpoint for that particular GET request in your app.
Everytime you make a request to your server (for example a GET request to /my-request) nodejs/express are configured in MEAN.js so that your server will try to find the endpoint for that request, if it does not find any, that request will be handled by this particular code block (specified in /modules/core/server/routes/core.server.routes.js):
// Define application route
app.route('/*').get(core.renderIndex);
Which will basically render the index view.
I'm not sure if you're using a custom module or not, eitherway, if you want that request to be handled in a different way in MEAN.js, you can specify your endpoint in your custom module routes file (or in core.server.controller.js) like so:
// Define application route
app.route('/my-request').get(core.sendMyJSON);
Be careful, because this route must be placed before the one I mentioned earlier, otherwise your request will still be handled the same way and the index view will be rendered and served again.
Then you will have to create the controller that should be called to handle that request:
exports.sendMyJSON = function (req, res) {
// logic to serve the JSON file
};
This way you should be able to get it done with a few adjustments.
Side note:
I'm not entirely sure but I think if you place your JSON file in the public directory of your app you should be able to directly access it without the need for the extra logic.
I am trying to build my application's admin UI using sling's userManager REST interface, but I would like to customize the json rendering. For example, I would like the response of "Get group" to include the members only if the requestor is a member.
I started by adding libs/sling/group/json.esp but I don't understand how I can get hold of the default response and customize it. Even if I had to query and form the json from scratch, where can I find information about APIs available to get this data from JCR/Sling?
I found that I could use ResourceTraversor to dump the resource object in json form but using new Packages.org.apache.sling.servlets.get.impl.helpers.ResourceTraversor(-1, 10000, resource, true) in the esp throws up an error
There are a few things to note here.
First, you should avoid putting your code under the libs directory. Your app code should live under the apps directory. When attempting to resolve a servlet for a URI, Sling will check apps before it checks libs so if you need to completely override functionality delivered with Sling, you would place your code in apps.
Second, what is (probably, depending on how you have things setup) happening when you request http://localhost:8080/system/userManager/group/administrators.tidy.1.json is the request is being handled by Sling's default GET servlet, because it finds no other script or servlet which is applicable. For research purposes it might be worth looking at the code for the default get servlet, org.apache.sling.servlets.get.impl.DefaultGetServlet, to see what it's using to render JSON. If you need to handle the rendering of a user group in a manner different than what the default GET servlet is doing, then you would need to create a servlet which is listening for requests for resources of type sling/group. It would probably be ideal to create a servlet for this purpose and register it with OSGI. http://sling.apache.org/site/servlets.html provides the various properties you would need to set to ensure the servlet resolver finds your servlet. Your servlet then would handle the request and as such would have direct and easy access to the requested resource.
Third, the particular need you specified is that you do not want the group members to render unless the requesting user is a member of the group requested. This is more of an access control issue than a rendering issue. Sling and Jackrabbit, out of the box, make as few assumptions as possible concerning how you might want your application to be setup. That being the case, you need to establish the access controls that are applicable for your particular use case. The wiki post on Access Control in the Jackrabbit wiki ( http://wiki.apache.org/jackrabbit/AccessControl ) goes into this to an extent.
Using directions from Paul Michelotti's answer, I researched further and found a suitable solution to my problem.
Sling accepts request filters (javax.servlet.Filter) through SCR annotations like the one below
#SlingFilter(scope = SlingFilterScope.REQUEST, order = Integer.MIN_VALUE)
Every request is passed down to the filter before it is processed by the servlet. Using the resourceType, I was able to distinguish requests to group.1.json and group/mygroup.1.json. Since the filter also has access to the current user, I was able to decide to deny the request if it did not abide by my security model and return a 404 status code.
Please refer to this page for details on filters. You can also check out the sample project urlfilter for directions on usage.
Not a great title but I'm looking more for some guidance, have searched quite a bit. I'm building a web app with an MVC framework (but I think this is a more generic question). I'm trying to make many views that do a lot of AJAX style calls and say I have a site with users and they can add folders and files to their profile page. So the URL maybe like:
/profile/{id}
I have a Profile controller that returns a view with various information. I'd like files and folders listed on the profile to be dynamic so I want to populate it through AJAX calls. I was thinking I would have a URL like
/listFolders/{userId}
and
/listFiles/{folderId}
Is it reasonable to have these URLs return a JSON object for these two URLs and not even provide an HTML view (since, for the browser, the view will just be the whole profile page)? Also, what should I return for errors, say if the user/folder doesn't exist or the current logged in user doesn't have access the data? Is it reasonable to just set 404 or 403 HTTP error codes or do they need to return some kind of HTML? What if there are multiple reasons for it to fail and I'd like to pass that along? Should I arbitrarily choose HTTP error codes or define integer return codes like 0, 1, 2, etc? Also, should the URL specify that they are JSON, like listFoldersJSON instead of listFolders?
I have used JSON in my previous projects. For errors, we return error codes.
We decided to do so because we were dealing with API clients. So we want to deal with error codes (REST is based on HTTP, so it was appropriate to return error codes).
Since you are writing your own application, you can pretty much choose how you want to send your errors to the view. You can create a error json object and in the view you have to check whether this object is not null.
pretty much a if-else in the view. Else you can return error codes and check for the code before rendering the JSON into whatever view you want to.
I would go with error codes, because that complies with the REST philosophy.
Generally speaking, I handle this situation by throwing a 500 internal server error with a status message. Most client libraries such as jQuery provide built in error handling with a failure callback like:
jQuery.ajax({
success:function(response){
//do some success stuff
},
error:function (xhr, ajaxOptions, thrownError){
//handle error
alert(xhr.responseText);
}
});
It's entirely feasible to return JSON objects as opposed to actual views.
As far as the url, you can use listFolders and listFiles without taking on the JSON. However, I recommend you use lower case urls for the sake of how the server is setup. For instance, I know on Apache that sometimes listFiles would be fine, but listfiles would lead to missing page exception.
With regards to errors: You could setup a header of sorts in your JSON response and use whatever system you'd like. For instance, you could do something like
status_code: 0 //where 0 means successful
status_detail:success!
Where, if the status_code is something other than 0, you'd check the status_detail and know to ignore everything else inside the response.
Also, what should I return for errors, say if the user/folder doesn't exist or the current logged in user doesn't have access the data?
These are basic HTTP Error codes:
401 : Unauthorized
404 : Not found
There's a whole slew of error messages in the HTTP spec:
HTTP Status Code Definitions
Also, should the URL specify that they are JSON, like listFoldersJSON instead of listFolders?
Generally, a good way to handle this is for the client to set the 'accepts' header to something like 'text/json' or 'text/xml' and for the server to parse it out and respond with the correct response. This way you can use the same URL but send back different views of the data (if you ever wanted)
I'm trying to standardize the way I handle exceptions in my web application (homemade framework) but I'm not certain of the "correct" way to handle various situations. I'm wondering if there is a best practice from UI/ user-friendly point of view.
User logs into application and opens two tabs showing the same screen. On one tab they issue a delete command on object FOO. Then, in the other tab they then click the edit command on FOO (which no longer exists); e.g. a GET request for editObject.php?object_id=FOO. What should I do when they issue the edit request for this nonexistent object?
-Currently I am redirecting these "missing" objects to the previous page with an error message like "object does not exist".
User issues a GET request to search for Objects with color=Red, e.g. searchObjects.php?color=Red. The query returning these results blew up because somebody dropped the OBJECTS table. This is an unexpected exception and isn't quite the same as 1).
-Currently I am redirecting to errorPage.php with a message "Unexpected error"
In general, what should I do if GET/POST parameters that should be there are instead mysteriously missing. Perhaps somebody is trying to inject something?
-Currently I am treating these the same as 2)
What should I be doing in each of the above 3 cases?
Render a "Object does not exist" view at the url editObject.php?object_id=FOO
Redirect to a controller that displays an error view: header('Location: errorPage.php')
Serve a 404: not sure of the syntax for doing this in PHP/Apache
Other
I'd say render it and serve a 404. That way, the user has the chance to see where they went wrong in the URL, or copy & paste it. If you redirect to a generic error page, they don't have that chance.
The PHP way to serve a 404 is
header("HTTP/1.0 404 not found");