4

I'm working on updating a component for Joomla 4. In the code, there are various bits where we raise an error code when for example the user is not authorised to access a certain part. For example in pre-Joomla 4 the code we used is as follows:

JError::raiseError(403, JText::_('JERROR_ALERTNOAUTHOR'));

Looking at various coding examples, I have seen different ways of raising the error in Joomla 4.

  1. $app->enqueueMessage(Text::_('JERROR_ALERTNOAUTHOR'), 'warning');
    $app->setHeader('status', 403, true);
    

    sometimes this example is without the second line in which the header is set.

  2. throw new NotAllowed(Text::_('JERROR_ALERTNOAUTHOR'), 403);
    
  3. Log::add(Text::_('JERROR_ALERTNOAUTHOR'), Log::ERROR, 'jerror');
    
  4. throw new \Exception(Text::_('JERROR_ALERTNOAUTHOR'), 403);
    

I am interesting in know of any other alternatives. Can anyone explain the difference between the examples I have given? What are the reasons for using one over another?

1
  • 1
    A great question; well-researched. More questions like this in this community please.
    – mickmackusa
    Nov 25 at 23:34
3

In #1 the first line of the first method will output a message to the next page that is displayed to user after the processing has completed so this is a nice simple way to inform that user that they have an authorisation issue, it doesn't have to be a 403. You could do more processing and provide more meaningful messages that reflect the actual access issue. For example "You need to be logged in to view this page" or "you do not have the required access level to view this page".

The second line is making the issue a Html Error 403, which is optional and not required in my view if you still have control of the processing and can provide a meaningful application related error or message. There is also a conflict between issuing a 'warn' message with a 403 which should be an 'error' in my view.

#2 example throws an exception message for a condition you are specifically looking for, a not authorised situation, and you want to stop further processing and access and produce a Html Error 403. Again if your authorisation issue is within your extension then I don't think a Html 403 error is appropriate unless you are trying to access some Html resource.

#3 writes a message to the Log defined in the extension but does not show anything to the user. You would use this is cases where you want to record particular messages for diagnosis or auditing. It could be used in addition to any of the other examples to record what is happening, but a 403 is very generic and would be better to record more diagnostic and useful details.

#4 Is another exception but for a situation that has occurred that you haven't prepared for, is unexpected, so it is a default catchall that will stop processing and in this example produce a 403 Html Error which may or may not be the correct error number to produce

I would use #1, first line at least, in most cases and in particular if you want to inform the end user of the status, (success,Info,warn,error),of processing in your code.

Next would be #2 where you want to stop processing because a condition that you have predicted might occur has been met that can't be dealt with in your code, but rarely will that be a Html 403

And then #4 would be something you would see in places where there is potential for an authorisation issue to come back that you don't know what it will be and you want to play it safe and stop processing. A call to a database or API or some other processing that happens outside of your control where you are attempting to login or provide credentials are good candidates for this type of exception that might warrant a Html 403 but you would be better off reading up on exception handling and seeing if you can trap the message coming back from the external processing and reflect that message instead of a generic 403.

#3 could be inserted before #1,#2 & #4 or after #1 if you want to record the issue.

2
  • You have partially touch on the subject of Http Status Codes. Is preferable to use #1, #2 or #4 according the http status code, e.g. 404 vs 403 or 5xx vs 4xx? Second, is it better to use one error handling #1, #2 or #4 according to where in the MVC model there error is raised, in particular in the controller or the model? 17 hours ago
  • My view is that if the error relates to the HTML aspects of your website, things like pages not found or not being able to access a folder on the server then you would be dealing with HTML errors as they would be outside the control of your application. If it is within your application then you should manage it with your own messages and not use HTML codes. For example if the user doesn't have an access level to a view a record in your application then that is something your application handles, is a not a HTML 403, and would be a #1 using the first line only.
    – Irata
    6 hours ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.