Bug: Data fields starting with a slash are interpreted as URI

[tft7000]

I have a alpaca json form with a string. I preload the data with a string that starts with a slash (eg. /bla).
The browser will present an error dialog 'Unable to load data from uri : /bla'.
This happens in Safari and Firefox.
It seems not to be dependent on the field type - I tried it on the alpaca documentation page with many different form elements (edit code, change a data field to "/bla", click run code).
Of course the same thing is happening if the string starts with http://. I assume other uris are also interpreted.

btw: you get very interesting effects, if you add an existing json file into the data field, eg. http://www.alpacajs.org/examples/forms/customer-profile/options.json. The form will look 'slightly' different.

I assume this behavior is a bug and a security bug if the user can enter data that get presented again the next time the form is getting called. At least I should be able to decide if the string should be interpreted or not.

[tft7000]

hmm, I found out, if I add to the schema "format": "uri", the field will not get interpreted as a uri.
Does this mean, that I would have to add this parameter to every field to be secure?
I might understand to less, but it still feels like a bug - please correct me, if I am wrong.

[uzquiano]

It's not a bug. If anything, it's probably a poor design choice and something that we should correct.

The goal is to support dynamic loading of data, schema and options settings from remote data sources. For example, you might want to load the data that you're going to display in your form from a NodeJS server talking to MongoDB. Thus, with Alpaca, you can do things like:

$.alpaca({
"data": "http://myserver.com/data"
});

However, we also wanted it to be the case that you could load data from absolute and relative web server paths, thus you can also reference paths like:

$.alpaca({
"data": "/virtualdirectory/data.json",
"schema": "./form.schema",
"options": "../dir/options.json"
});

And so forth (absolute and relative paths). Thus, when Alpaca looks at the values for data, schema and options, it tries to make a best guess as to whether you're referring to static value (like a string) or a remote URI. Unfortunately, that decision precludes using strings that start with "/", "./" or "../" since that's how Alpaca decides whether it's a remote address or not.

Since JSON schema supports format:uri for identifying URIs explicitly, it seems like fair game to ask people to spell out this treatment in their schemas. However, that's really just from a data modeling point of view. Ideally, it shouldn't impact how Alpaca works or behaves at all.

I think the real issue here is that Alpaca is changing its behavior based on the values of these strings and isn't letting the user know. In addition, it's imposing some constraints on the values. For many folks, strings that start with "/" are practical and necessary (for storing directory paths, for example, or perhaps location strings into a product catalog).

There is probably a more elegant solution. I'd love to hear some proposals from the community!

[jdorn]

I understand parsing URIs at the top level like this:

$.alpaca({
"data": "/virtualdirectory/data.json",
"schema": "./form.schema",
"options": "../dir/options.json"
});

The problem arises when Alpaca tries to parse URIs within the "data" object like this:

$.alpaca({
"data": {
    "test": "/"
},
"schema": "./form.schema",
"options": "../dir/options.json"
});

[ftrotter]

I am experiencing this bug too.
One of the things that I am keeping in the database is the url of various organizations.

I get the error: " Alpaca error was caught with default error handler: Unable to load data from uri : http://example.com"

But I did not want to "load data" from the url at all.. I just wanted to edit it like a normal text field...

Now there is no text field.

This is a pretty serious bug. The url autoloading essentially prevents any data management with data that includes urls. Most data includes urls now...

-FT

[chriswdixon]

We are experiencing this feature as well. I think the logic should be to add the format: uri if you want to load data, not the opposite. Once a user has put a URL or /bla in a field, the field errors and is no longer shown or editable.

-CD

[rkylberg]

This feature caught me as well; however, once you figure out that you must specify string fields that capture urls as: "format": "uri", then it makes sense.

I recommend improving the documentation of this feature rather then calling it a bug. Also, inverting the meaning as CD suggests would regress a decent amount of code we have written as per the current implementation.

[ftrotter]

The application is doing something counter intuitive "out of the box". In my book... thats a bug...

Also any kind of "automatically load a url" stuff is hacker-fodder...

As long as this was explained very clearly, and very prominently (i.e. in tutorials, etc and not just in API documentation) then I suppose that would be OK.

[uzquiano]

Great comments. All of the feedback is very useful and right on.

One approach which I've recommended on another thread but which I think applies here is for us to introduce three new configuration options -

1. dataSource
2. schemaSource
3. optionsSource

We could have "data", "schema" and "options" be data-only in that we'd remove the questionable "auto-loading" capability which is currently in place for anything that looks like it might be a URL. These fields would be treated solely as data.

And if the "dataSource", "schemaSource" or "optionsSource" fields are provided, then those would be treated either as a URL or as a function that asynchronously loads and passes the JSON to a callback.

I think this offers the greatest flexibility and while it's incompatible with the current implementation, I feel the separation of concerns would have some nice payoff down the road.

Also, as @ftrotter and others have pointed out, the currently approach is counter intuitive and that's never a nice thing for open source. While the format "uri" approach works, it isn't obvious. In every other case I can think of, the "format" property is a modifier to behavior for the control and not required in order to make it function properly.

What do you guys think of this approach?

I know this will impact the code of anyone relying on the auto-loading capabilities of the current properties. Is it worth it to you guys to make a cutover at this time?

[uzquiano]

This is now implemented in 1.1.0 (which was just released). Alpaca now allows for URIs in data fields without any issue. The new configuration properties (dataSource, schemaSource, optionSource and viewSource) allow for dynamic loading from external URIs.

As such, I'll close this issue. If anything related to this crops up again, feel free to re-open or to submit a new issue.

[ftrotter]

bravo!