[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixing "stringly typed" data structures in Artanis (Was: Learning Gu

From: Nala Ginrut
Subject: Re: Fixing "stringly typed" data structures in Artanis (Was: Learning Guile web. Stuck on returning an image.)
Date: Fri, 11 Dec 2015 15:33:52 +0800

Actually, all of these issues (better rule parsing, anti
SQL-injection...) have been concerning when developing Artanis.
And I've prepared something for them in Artanis, but all these new
solutions are still premature. It's why I didn't announce them.

1. For better rule parsing
In the beginning, I plan to mimic the way of mainstream web framework to
provide string rule parsing for URL-remapping. This would be easier for
newcomers to learn Artanis from other framework (Django/Rails...).

This string rule parsing implementation is complete and stable now.
So yes, it's time to think about a better solution now, which may show
some benefit when people come to Scheme.

Fortunately, Artanis is flexible enough to add new list parsing for
URL-remapping. So we may provide both in Artanis, say:
(get '(img s.jpg) ...)
(get '(img (: jpgfile)) ...)

Folks may dislike (: key) to indicate binding in URL, but it's trivial
here. Anyway, it's possible to provide list matching for URL-remapping
without refactoring Artanis.
(provide both string and list pattern is seen in Irregex, I think it's

The only problem is how to design a good list pattern for URL-mapping.
IMO, it's a new Domain-Specific-Language too, just like the current one.
But it's more natural and expressive in list.

2. DB security and efficiency, anti-SQL-injection

This is a big and hard topic, although one may achieve something in
limited situations.

Yes, there's possibility that we can detect/filter bad strings in URL
rules within list matching.
But that's bad solution.

DB operation should be decoupled from URL-remapping. So I'll be unlikely
to add such filter in list-URL pattern matching, although it's trivial
to add.

The solution Artanis provided is SQL-mapping, which is undocumented yet.
Because it's still premature.
It'll provide a mechanism for user to define their own filter to make
sure every fields/values is safe before passing it to Database. Besides,
there could be a syntax analyzer to check if the whole concatenated SQL
string is safe (yes it's hard, but it's the policy, here I'm just
talking about mechanism).

Beyond, as we know, Relational-Mapping is not silver bullet for any
cases. Personally, I've seen huge SQL code block in hundreds lines in
product environment. If your business need such complex query, it's
never Relation-Mapping can solve. People should write fancy SQL code
But how to interact with users input from client? And how to do proper
check/filter for SQL? How can such a mapping be used in users code
easily? That's what SQL-mapping trying to solve.

3. Conclusion

I plan to add list matching for URL-remapping in future release. Maybe
it's a good time to discuss how to design the pattern (actually it's a
new DSL) now?

The proper design is important for Artanis, since most of the URL routes
would be generated automatically if users use CLI tools to save their
time (maybe it's trivial since the generated rules unnecessary to be
list). Of course, it is never a problem for Scheme because of the
expressiveness. ;-) 

On Thu, 2015-12-10 at 17:02 -0500, Thompson, David wrote:
> I guess this is as good a time as any to voice a concern that I have
> with Artanis before too many people depend on it and its not feasible
> to change it.  In Scheme, we have the luxury of being able to easily
> create embedded domain specific languages or otherwise take advantage
> of s-expressions to avoid the tiring work of writing parsers and
> interpreters for new languages.  However, Artanis features a URI
> routing language written in strings, like "/user/:id".  This
> particular string means: Match a URI beginning with "/user/", followed
> by any string and associate it with the name "id".  Generally
> speaking, this is a pattern matcher.  Unfortunately, unlike Guile's
> built-in pattern matcher, these patterns must be string encoded and
> cannot do more sophisticated matching techniques such as making sure
> "id" is a string representation of an integer.  Doing this type of
> string-based URI matching is the status quo in many web frameworks
> written in Ruby, Python, etc., but in Scheme we have the opportunity
> to do *much* better.  For an example that uses more proper Guile
> Scheme idioms, take a look the source for the 'guix publish' tool in
> GNU Guix. [0]  By viewing a URI as a list strings, we can represent
> "/user/1" as the list ("image" "1").  From there, it's easy to use a
> pattern matcher to match this route:
>     (match uri (("user" id) (display-user-info id)))
> From there we can get more advanced and assert various things about
> "id" in the match expression, as 'guix publish' does with its routes.
> There are also security issues to think about when you use "stringly
> typed" data.  It doesn't apply to this particular case, but working
> with strings that are actually not strings (like HTML or SQL) opens
> the door for injection attacks. [1] Fortunately, we can avoid such
> issues entirely by choosing more appropriate data types.
> I hope this has made some sense.  I think Artanis is a great project,
> and I hope issues like this can be fixed so web developers looking at
> Guile can truly see how much better it is in Lisp land.
> - Dave
> [0] 
> [1]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]