__color__ ticket summary component version milestone type owner status created _changetime _description _reporter 3 3 Distinct IContinuation types/parameter names clavis defect smagi new 2014-11-10T12:23:26-0500 2014-11-10T12:24:34-0500 "Need to add runtime checks to ensure that the type parameters to IContinuation are: 1. all distinct types, and 1. not T at one arg, and IEnumerable at another arg It would be nice if at least 1 could be enforced statically, but I don't see a way to do it. IContinuationX could implement a basic IParam interface, but if you try to implement it for multiple type parameters, you get an error: {{{ // error: 'IContinuation' cannot implement both 'IParam' and 'IParam' because they may unify // for some type parameter substitutions public interface IContinuation : IParam, IParam { } }}} Basically, this is only an error when defined for the same type parameters at the *use* site, not at the *declaration* site, but C# doesn't defer this check as I think it should. This still wouldn't help for case 2 though, so we need a runtime check regardless. Fortunately, this can be checked once when the type is first loaded as a continuation." smagi 3 5 Make URLs case insensitive? clavis defect smagi new 2014-11-10T12:28:58-0500 2014-11-10T12:28:58-0500 Current HMAC and type resolution logic depends on case. It might be better to default to case insensitive HMAC. smagi 3 4 Privileged first parameter clavis enhancement smagi new 2014-11-10T12:27:59-0500 2014-11-10T12:27:59-0500 "It would be convenient to fold the first parameter of a resource into the URL path itself. This would support wiki-like naming, so instead of /View?Page=FooBar clients would see some varient of /View/FooBar. However, since the URL path is part of the HMAC, this means the path component must be a protected parameter. However, it's more desirable if this component were unsafe/unprotected so clients could change it at will. Furthermore, the first parameter of a resource must be the same across all continuation types it implements, and it cannot be an IEnumerable type. Possible resolutions: 1. Path is not included in the HMAC: this would allow illegal continuation applications, ie. moving query string from one continuation to another would be allowed, but be an error. 1. Require a continuation value for validation: this is how it used to work before switching to purely URL-based validation. However, how would a Clavis HttpHandler find and load the right continuation type given only the string? We can't know just by looking at the requested URL whether it's a continuation type that folds the first parameter into the path. 3. Use a distinct character to delimit path from param, ie. /View:FooBar or /View-FooBar. This makes it somewhat non-uniform with other URLs, but not entirely so, ie. Wikipedia talk page uses ""/wiki/Talk:Subject"". See: http://stackoverflow.com/a/4669755/144873 I think #3 is the best option: unsafe integral first params can be folded into the URL path with a "":"" delimiter. HMAC validation will simply skip all data between "":"" and ""?"". Perhaps a different delimiter, like '-', will designate protected params which are included in the HMAC. Or perhaps more convenient URLs can be controlled at a whole other layer, like with IIS URL rewriting?" smagi 3 6 Fully qualified name <=> URL mapping clavis enhancement smagi new 2014-11-10T12:36:55-0500 2014-11-10T12:37:03-0500 "Clavis currently relies on some third-party component to resolve a continuation types from URLs. Future enhancements will require Clavis to perform this task as well, but: 1. Type URLs are ambiguous because the assembly name isn't part of the URL. 1. The UrlAttribute allows continuations to declaratively customize their path. The first could be resolved by a backwards incompatible change that includes the assembly in the path, ie. Foo.Bar, Baz <=> Baz-Foo/Bar, instead of just Foo/Bar as it currently is. The second seems to necessitate a global assembly search for custom URL paths. Since we have to do this search anyway, it seems prudent to build the global mapping table at this point too instead of loading each mapping on demand." smagi 4 2 Make Unsafe safer clavis defect smagi new 2014-11-10T12:09:31-0500 2014-11-10T12:09:31-0500 "Unsafe currently exposes a Value property, which makes it very easy to use in an unsafe context: {{{ string sql = ""SELECT * FROM Foo WHERE "" .. Unsafe someProp; if (this.TryParse0(out someProp)) sql += "" SomeProp = '"" + someProp + ""' AND ""; ... }}} I want to discourage such horrible implementations by making it difficult to extract and use possibly unsafe values. It's not clear how to do this however. Even a TryGetValue-type interface, while more annoying, is still easy enough to circumvent: {{{ string sql = ""SELECT * FROM Foo WHERE "" .. Unsafe somePropUnsafe; string someProp if (this.TryParse0(out somePropUnsafe) && somePropUnsafe.TryGetValue(out someProp)) sql += "" SomeProp = '"" + someProp + ""' AND ""; ... }}} Perhaps we could attach some sort of validator to an unsafe value's TryGetValue: {{{ string sql = ""SELECT * FROM Foo WHERE "" .. Unsafe somePropUnsafe; if (this.TryParse0(out somePropUnsafe, Sql.StringValidator)) sql += "" SomeProp = '"" + someProp + ""' AND ""; ... }}} This would work for simple values, but the SQL example clearly shows that you have to be able to parse full SQL to ascertain whether the string is actually safe. This doesn't seem reasonable." smagi 4 1 String-based parameter names clavis enhancement smagi new 2014-11-10T11:57:55-0500 2014-11-11T01:19:02-0500 "Currently Clavis requires one to define simple wrapper classes to generate parameter names. While simple, this is a bit heavy handed. A possible future change to support more flexible naming consists of using attributes on continuation type parameters: {{{ public class Foo : IContinuation<[Param(""First"")]string> { ... } }}}" smagi