[OKAPI-256] Verify redirect paths at module-enable time Created: 13/Feb/17  Updated: 14/Feb/17  Resolved: 14/Feb/17

Status: Closed
Project: Okapi
Components: None
Affects versions: None
Fix versions: None

Type: New Feature Priority: P3
Reporter: Heikki Levanto Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 3 hours
Original estimate: Not Specified

Issue links:
Relates
relates to OKAPI-244 implement redirect/passthrough routing Closed
Sprint:

 Description   

The proxy catches bad redirects at run time, but it would be good to check them already when installing modules and/or enabling them for a tenant.



 Comments   
Comment by Heikki Levanto [ 13/Feb/17 ]

This is a bit tricky to implement, and not really needed right now, so I am postponing it.

Comment by Heikki Levanto [ 13/Feb/17 ]

Basically, what needs to be done, either at module install and/or module enabling time, is to check that

  • The given module has a redirect to some path
  • Such path exists among the modules that provide those interfaces that our module depends on

Also, watch out for too trivial match on the paths - see OKAPI-253 Closed for a prefix match by a path component instead of plain string.

Comment by Jakub Skoczen [ 14/Feb/17 ]

I think for this to make sense it would also need to get verified when a module being redirected to gets removed.

..which makes me think whether we are not duplicating the "dependency checking" functionality here. Shouldn't the module be allowed to only redirect to the modules it depends on? And this is then being handled automatically by the dependency mechanism?

Comment by Heikki Levanto [ 14/Feb/17 ]

As you pointed out in our discussion, the current dependency check is sufficient for checking the dependencies explicitly listed in the ModuleDescriptor. If a module makes a request to another module without declaring the dependency, we can never know. Not checking for redirects is a similar case. Probably safe to ignore for now.

Generated at Thu Feb 08 23:06:03 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.