lupinia
commented
1 year ago This turned out to be simpler than I thought: It only affected special filter views (which correspond to query parameters instead of database objects), because all other types of filters used get_object_or_404() to look up the current filter before any other context operations happened. That's not an option for deerattend.views.events_by_special, so it pulls from a dictionary using the .get() method, and returns False if it was an invalid slug. So, I've added a check to see whether the current filter is False before proceeding with any further context processing, and it raises a 404 if it couldn't match a filter - given the code structure, I think that was my intent from the beginning, I just forgot to actually do it at the time.
Discovered by a crawler trying to inject bad data at the end of every URL, but it's a problem nonetheless: The new title handling code from #88 happens too early in DeerAttend filter views, and attempts to directly access
context['cur_filter']['name']before it has verified thatcontext['cur_filter']even exists. Which may actually be the symptom of a deeper issue, I need to look more closely to be sure.