Severe bug: Query parameters are not being encoded about auto_route_library

[quaaantumdev]

@rsegecin not sure if you're understood that correctly. The example above shows two different routes, so two different pages using the same query parameter name. That should be fairly common. The routes are NOT instantiated at the same time, it just happens to be, that the value sent in the query parameter contains something (an url) that effectively as a "magic string" at the end. There is no reason, the router should care about the string content of the query parameter value. It should just be a string and arrive there, whatever it's contents may be. The router should encode whatever needs to be encoded to create a valid URL. By the way, it does that by using the Uri class internally. But after that, it decodes the URL with this strange function at a point where decoding does not even make sense nor is needed (I believe).

I did a bit more testing and i'am pretty sure the use of decodeFull in UrlState is simply incorrect.

Here is another case that may explain the issue:

/// the constructor of SomePage, registered as /some-route
SomePage({
  @QueryParam('myQueryParam') this.myQueryParam,
});

// now somebody calls
AutoRouter.of(context).replace(SomeRoute(
  // the following query parameter value may seem silly but there is no reason this should not be possible
  // it's just a string that needs encoding
  myQueryParam: "?=:http://&"
));

// i did not test this case explicitly but i am pretty sure the resulting url is will be something like that:
//   /some-route?myQueryParam=?=:http://&
// but it should actually be:
//   /some-route?myQueryParam=%3F%3D%3Ahttp%3A%2F%2F%26

// the reason is, that the parameters need to be encoded but that is not the case 
// because Uri.decodeFull simply decodes everything, discarding any association
// of the query parameter and it's value. 

Also see the documentation of Uri.decodeFull (https://api.flutter.dev/flutter/dart-core/Uri/decodeFull.html), it notes:

Note that decoding a full URI might change its meaning as some of the decoded characters could be reserved characters. In most cases, an encoded URI should be parsed into components using Uri.parse before decoding the separate components.

[rsegecin]

I've never encountered a web framework or library that accepts query parameters named in the manner you're suggesting, such as having multiple parameters with the same name like "redirectTo". This practice may lead to confusion and unexpected behavior during URL parsing.

A more conventional approach would be to implement redirection logic using guards. After processing user login data, you can store relevant information in cookies. Then, utilize guards to analyze the cookie data and redirect users accordingly. For scenarios like onboarding processes where multiple redirection paths may be necessary, employing multiple guards can help manage the redirection flow effectively.