I'm trying to use Smuggler to export a single document from an embedded database that does not use the embedded. I'm getting URI format errors from HttpRavenRequest. Can this be done? If so, where am I going wrong in the test below:
Thanks :)
[Test] public void can_export_document_by_id() { using (var store = new EmbeddableDocumentStore { DataDirectory = "Data", RunInMemory = true, UseEmbeddedHttpServer = false })
{ store.Initialize();
var company = new Company {Name = "Sean"}; using (var session = store.OpenSession()) { session.Store(company); session.SaveChanges(); }
var api = new SmugglerApi(new EmbeddedRavenConnectionStringOptions { DataDirectory = "Data", AllowEmbeddedOptions = true, }); var options = new SmugglerOptions { File = @"c:\users\sean\desktop\sean.raven" }; options.Filters.Add("Id", company.Id); api.ExportData(options); } }
> I'm trying to use Smuggler to export a single document from an embedded
> database that does not use the embedded. I'm getting URI format errors
> from HttpRavenRequest. Can this be done? If so, where am I going wrong in
> the test below:
> Thanks :)
> [Test]
> public void can_export_document_by_id()
> {
> using (var store = new EmbeddableDocumentStore { DataDirectory = "Data", RunInMemory = true, UseEmbeddedHttpServer = false })
> {
> store.Initialize();
> var company = new Company {Name = "Sean"};
> using (var session = store.OpenSession())
> {
> session.Store(company);
> session.SaveChanges();
> }
> var api = new SmugglerApi(new EmbeddedRavenConnectionStringOptions { DataDirectory = "Data", AllowEmbeddedOptions = true, });
> var options = new SmugglerOptions { File = @"c:\users\sean\desktop\sean.raven" };
> options.Filters.Add("Id", company.Id);
> api.ExportData(options);
> }
> }
I'm going to be running on the user's desktop and I don't want to have the embedded http server running so that I can lock down the system so that users can't tamper with the data in any way.
Is there any other way I can use to export documents and attachments?
Also, I have just realised that even if I encrypt the documents in the database, the user could download and run Studio against the data. Is there any way currently of preventing this, such as whole database encryption? If not, will that be available with the encryption features in 1.2?
Sean,
If the data is on the user's computer, he got it.
Oh, you can make it awkward to get it, but they can do that.
There is literally no way to hide that if your are running on his machine.
I think that there is some code around (Tobi or Justin wrote it, I believe)
that will work like the smuggler for the embedded version.
On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon <kearon.s...@googlemail.com>wrote:
> I'm going to be running on the user's desktop and I don't want to have the
> embedded http server running so that I can lock down the system so that
> users can't tamper with the data in any way.
> Is there any other way I can use to export documents and attachments?
> Also, I have just realised that even if I encrypt the documents in the
> database, the user could download and run Studio against the data. Is
> there any way currently of preventing this, such as whole database
> encryption? If not, will that be available with the encryption features in
> 1.2?
> Thanks
> Sean
> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>> You cannot export from an embedded DB without enabling the embedded http
>> server.
>> Smuggler works over HTTP.
On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
> Sean, > If the data is on the user's computer, he got it. > Oh, you can make it awkward to get it, but they can do that. > There is literally no way to hide that if your are running on his machine.
> I think that there is some code around (Tobi or Justin wrote it, I > believe) that will work like the smuggler for the embedded version.
> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>> Oren
>> I'm going to be running on the user's desktop and I don't want to have >> the embedded http server running so that I can lock down the system so that >> users can't tamper with the data in any way.
>> Is there any other way I can use to export documents and attachments?
>> Also, I have just realised that even if I encrypt the documents in the >> database, the user could download and run Studio against the data. Is >> there any way currently of preventing this, such as whole database >> encryption? If not, will that be available with the encryption features in >> 1.2?
>> Thanks
>> Sean
>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>> You cannot export from an embedded DB without enabling the embedded http >>> server. >>> Smuggler works over HTTP.
At the end, it is a file on his machine.
Sure, you can encrypt that, but the encryption key also has to be on the
machine at some point, so that is pretty meaningless.
Who is the user? What is the data? How important is it to prevent
tampering? Are you likely to be dealing with devs / hackers or with
standard users?
On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon <kearon.s...@googlemail.com>wrote:
> As for the user accessing the data - so there is no way that I can prevent
> the user from editing or deleting documents whatever lengths I go to?
> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>> Sean,
>> If the data is on the user's computer, he got it.
>> Oh, you can make it awkward to get it, but they can do that.
>> There is literally no way to hide that if your are running on his machine.
>> I think that there is some code around (Tobi or Justin wrote it, I
>> believe) that will work like the smuggler for the embedded version.
>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>> Oren
>>> I'm going to be running on the user's desktop and I don't want to have
>>> the embedded http server running so that I can lock down the system so that
>>> users can't tamper with the data in any way.
>>> Is there any other way I can use to export documents and attachments?
>>> Also, I have just realised that even if I encrypt the documents in the
>>> database, the user could download and run Studio against the data. Is
>>> there any way currently of preventing this, such as whole database
>>> encryption? If not, will that be available with the encryption features in
>>> 1.2?
>>> Thanks
>>> Sean
>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>> You cannot export from an embedded DB without enabling the embedded
>>>> http server.
>>>> Smuggler works over HTTP.
The end users are electrical engineers as private engineers or companies. The product is licensed to the PC itself and we do eperience a fair amount of end user tampering. Part of the licensing and machine locking is tracked in the database itself, so it['s important that they cannot remove this.
The other motivation is to prevent competitors from accessing our data. To be able to upgrade from our data is an attractive selling point and I'm a small guy in a market where there are some very established players who have far more resources that I do. That precise scenario happened to me about 10 years ago now, and it hurt!
The encryption key is shipped, yes, but it's obfuscated. Sure, you can never totally prevent access, but to raise the bar to the level that the attacker has to crack commercial obfuscation is good enough for our needs. At least I then have legal recourse if that were a competitor.
So, is there any way currently or in the fairly near future to prevent user tampering? It sounds from your responses that there isn't, which would be a shame.
On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
> At the end, it is a file on his machine. > Sure, you can encrypt that, but the encryption key also has to be on the > machine at some point, so that is pretty meaningless.
> Who is the user? What is the data? How important is it to prevent > tampering? Are you likely to be dealing with devs / hackers or with > standard users?
> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>> Thanks, I'll look for Tobi or Justin's code.
>> As for the user accessing the data - so there is no way that I can >> prevent the user from editing or deleting documents whatever lengths I go >> to?
>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>> Sean, >>> If the data is on the user's computer, he got it. >>> Oh, you can make it awkward to get it, but they can do that. >>> There is literally no way to hide that if your are running on his >>> machine.
>>> I think that there is some code around (Tobi or Justin wrote it, I >>> believe) that will work like the smuggler for the embedded version.
>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>> Oren
>>>> I'm going to be running on the user's desktop and I don't want to have >>>> the embedded http server running so that I can lock down the system so that >>>> users can't tamper with the data in any way.
>>>> Is there any other way I can use to export documents and attachments?
>>>> Also, I have just realised that even if I encrypt the documents in the >>>> database, the user could download and run Studio against the data. Is >>>> there any way currently of preventing this, such as whole database >>>> encryption? If not, will that be available with the encryption features in >>>> 1.2?
>>>> Thanks
>>>> Sean
>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>>> You cannot export from an embedded DB without enabling the embedded >>>>> http server. >>>>> Smuggler works over HTTP.
> The end users are electrical engineers as private engineers or companies.
> The product is licensed to the PC itself and we do eperience a fair amount
> of end user tampering. Part of the licensing and machine locking is
> tracked in the database itself, so it['s important that they cannot remove
> this.
> The other motivation is to prevent competitors from accessing our data.
> To be able to upgrade from our data is an attractive selling point and I'm
> a small guy in a market where there are some very established players who
> have far more resources that I do. That precise scenario happened to me
> about 10 years ago now, and it hurt!
> The encryption key is shipped, yes, but it's obfuscated. Sure, you can
> never totally prevent access, but to raise the bar to the level that the
> attacker has to crack commercial obfuscation is good enough for our needs.
> At least I then have legal recourse if that were a competitor.
> So, is there any way currently or in the fairly near future to prevent
> user tampering? It sounds from your responses that there isn't, which
> would be a shame.
> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>> At the end, it is a file on his machine.
>> Sure, you can encrypt that, but the encryption key also has to be on the
>> machine at some point, so that is pretty meaningless.
>> Who is the user? What is the data? How important is it to prevent
>> tampering? Are you likely to be dealing with devs / hackers or with
>> standard users?
>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>> Thanks, I'll look for Tobi or Justin's code.
>>> As for the user accessing the data - so there is no way that I can
>>> prevent the user from editing or deleting documents whatever lengths I go
>>> to?
>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>>> Sean,
>>>> If the data is on the user's computer, he got it.
>>>> Oh, you can make it awkward to get it, but they can do that.
>>>> There is literally no way to hide that if your are running on his
>>>> machine.
>>>> I think that there is some code around (Tobi or Justin wrote it, I
>>>> believe) that will work like the smuggler for the embedded version.
>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>>> Oren
>>>>> I'm going to be running on the user's desktop and I don't want to have
>>>>> the embedded http server running so that I can lock down the system so that
>>>>> users can't tamper with the data in any way.
>>>>> Is there any other way I can use to export documents and attachments?
>>>>> Also, I have just realised that even if I encrypt the documents in the
>>>>> database, the user could download and run Studio against the data. Is
>>>>> there any way currently of preventing this, such as whole database
>>>>> encryption? If not, will that be available with the encryption features in
>>>>> 1.2?
>>>>> Thanks
>>>>> Sean
>>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>>>> You cannot export from an embedded DB without enabling the embedded
>>>>>> http server.
>>>>>> Smuggler works over HTTP.
Sure, that does prevent a competitor from reading our data. But it doesn't prevent user tampering nor does it allow me to use the database to track licensing (as it can be tampered with). There's no way currently around that then?
On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
> Sean, > Encrypt the data, that should take you pretty far in only allowing access > from your own software.
> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>> The end users are electrical engineers as private engineers or companies. >> The product is licensed to the PC itself and we do eperience a fair amount >> of end user tampering. Part of the licensing and machine locking is >> tracked in the database itself, so it['s important that they cannot remove >> this.
>> The other motivation is to prevent competitors from accessing our data. >> To be able to upgrade from our data is an attractive selling point and I'm >> a small guy in a market where there are some very established players who >> have far more resources that I do. That precise scenario happened to me >> about 10 years ago now, and it hurt!
>> The encryption key is shipped, yes, but it's obfuscated. Sure, you can >> never totally prevent access, but to raise the bar to the level that the >> attacker has to crack commercial obfuscation is good enough for our needs. >> At least I then have legal recourse if that were a competitor.
>> So, is there any way currently or in the fairly near future to prevent >> user tampering? It sounds from your responses that there isn't, which >> would be a shame.
>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>> At the end, it is a file on his machine. >>> Sure, you can encrypt that, but the encryption key also has to be on the >>> machine at some point, so that is pretty meaningless.
>>> Who is the user? What is the data? How important is it to prevent >>> tampering? Are you likely to be dealing with devs / hackers or with >>> standard users?
>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>> Thanks, I'll look for Tobi or Justin's code.
>>>> As for the user accessing the data - so there is no way that I can >>>> prevent the user from editing or deleting documents whatever lengths I go >>>> to?
>>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>>>> Sean, >>>>> If the data is on the user's computer, he got it. >>>>> Oh, you can make it awkward to get it, but they can do that. >>>>> There is literally no way to hide that if your are running on his >>>>> machine.
>>>>> I think that there is some code around (Tobi or Justin wrote it, I >>>>> believe) that will work like the smuggler for the embedded version.
>>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>>>> Oren
>>>>>> I'm going to be running on the user's desktop and I don't want to >>>>>> have the embedded http server running so that I can lock down the system so >>>>>> that users can't tamper with the data in any way.
>>>>>> Is there any other way I can use to export documents and attachments?
>>>>>> Also, I have just realised that even if I encrypt the documents in >>>>>> the database, the user could download and run Studio against the data. Is >>>>>> there any way currently of preventing this, such as whole database >>>>>> encryption? If not, will that be available with the encryption features in >>>>>> 1.2?
>>>>>> Thanks
>>>>>> Sean
>>>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>>>>> You cannot export from an embedded DB without enabling the embedded >>>>>>> http server. >>>>>>> Smuggler works over HTTP.
> Sure, that does prevent a competitor from reading our data. But it
> doesn't prevent user tampering nor does it allow me to use the database to
> track licensing (as it can be tampered with). There's no way currently
> around that then?
> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>> Sean,
>> Encrypt the data, that should take you pretty far in only allowing access
>> from your own software.
>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>> The end users are electrical engineers as private engineers or companies.
>>> The product is licensed to the PC itself and we do eperience a fair amount
>>> of end user tampering. Part of the licensing and machine locking is
>>> tracked in the database itself, so it['s important that they cannot remove
>>> this.
>>> The other motivation is to prevent competitors from accessing our data.
>>> To be able to upgrade from our data is an attractive selling point and I'm
>>> a small guy in a market where there are some very established players who
>>> have far more resources that I do. That precise scenario happened to me
>>> about 10 years ago now, and it hurt!
>>> The encryption key is shipped, yes, but it's obfuscated. Sure, you can
>>> never totally prevent access, but to raise the bar to the level that the
>>> attacker has to crack commercial obfuscation is good enough for our needs.
>>> At least I then have legal recourse if that were a competitor.
>>> So, is there any way currently or in the fairly near future to prevent
>>> user tampering? It sounds from your responses that there isn't, which
>>> would be a shame.
>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>>> At the end, it is a file on his machine.
>>>> Sure, you can encrypt that, but the encryption key also has to be on
>>>> the machine at some point, so that is pretty meaningless.
>>>> Who is the user? What is the data? How important is it to prevent
>>>> tampering? Are you likely to be dealing with devs / hackers or with
>>>> standard users?
>>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>>> Thanks, I'll look for Tobi or Justin's code.
>>>>> As for the user accessing the data - so there is no way that I can
>>>>> prevent the user from editing or deleting documents whatever lengths I go
>>>>> to?
>>>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>>>>> Sean,
>>>>>> If the data is on the user's computer, he got it.
>>>>>> Oh, you can make it awkward to get it, but they can do that.
>>>>>> There is literally no way to hide that if your are running on his
>>>>>> machine.
>>>>>> I think that there is some code around (Tobi or Justin wrote it, I
>>>>>> believe) that will work like the smuggler for the embedded version.
>>>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>>>>> Oren
>>>>>>> I'm going to be running on the user's desktop and I don't want to
>>>>>>> have the embedded http server running so that I can lock down the system so
>>>>>>> that users can't tamper with the data in any way.
>>>>>>> Is there any other way I can use to export documents and attachments?
>>>>>>> Also, I have just realised that even if I encrypt the documents in
>>>>>>> the database, the user could download and run Studio against the data. Is
>>>>>>> there any way currently of preventing this, such as whole database
>>>>>>> encryption? If not, will that be available with the encryption features in
>>>>>>> 1.2?
>>>>>>> Thanks
>>>>>>> Sean
>>>>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>>>>>> You cannot export from an embedded DB without enabling the embedded
>>>>>>>> http server.
>>>>>>>> Smuggler works over HTTP.
Given that the documents can be encrypted and that (an equivalent to) Smuggler can be run without enabling http, then to require a password to enable http access to the database from would be all that's needed.
I presume that this, or something similar, is something that you're going to add for the enterprise encryption in 1.2?
On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
> Sean, > Let me rephrase that, what do you want? How do you envision it?
> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>> Sure, that does prevent a competitor from reading our data. But it >> doesn't prevent user tampering nor does it allow me to use the database to >> track licensing (as it can be tampered with). There's no way currently >> around that then?
>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>>> Sean, >>> Encrypt the data, that should take you pretty far in only allowing >>> access from your own software.
>>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>>> The end users are electrical engineers as private engineers or >>>> companies. The product is licensed to the PC itself and we do eperience a >>>> fair amount of end user tampering. Part of the licensing and machine >>>> locking is tracked in the database itself, so it['s important that they >>>> cannot remove this.
>>>> The other motivation is to prevent competitors from accessing our data. >>>> To be able to upgrade from our data is an attractive selling point and I'm >>>> a small guy in a market where there are some very established players who >>>> have far more resources that I do. That precise scenario happened to me >>>> about 10 years ago now, and it hurt!
>>>> The encryption key is shipped, yes, but it's obfuscated. Sure, you can >>>> never totally prevent access, but to raise the bar to the level that the >>>> attacker has to crack commercial obfuscation is good enough for our needs. >>>> At least I then have legal recourse if that were a competitor.
>>>> So, is there any way currently or in the fairly near future to prevent >>>> user tampering? It sounds from your responses that there isn't, which >>>> would be a shame.
>>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>>>> At the end, it is a file on his machine. >>>>> Sure, you can encrypt that, but the encryption key also has to be on >>>>> the machine at some point, so that is pretty meaningless.
>>>>> Who is the user? What is the data? How important is it to prevent >>>>> tampering? Are you likely to be dealing with devs / hackers or with >>>>> standard users?
>>>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>>>> Thanks, I'll look for Tobi or Justin's code.
>>>>>> As for the user accessing the data - so there is no way that I can >>>>>> prevent the user from editing or deleting documents whatever lengths I go >>>>>> to?
>>>>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>>>>>> Sean, >>>>>>> If the data is on the user's computer, he got it. >>>>>>> Oh, you can make it awkward to get it, but they can do that. >>>>>>> There is literally no way to hide that if your are running on his >>>>>>> machine.
>>>>>>> I think that there is some code around (Tobi or Justin wrote it, I >>>>>>> believe) that will work like the smuggler for the embedded version.
>>>>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>>>>>> Oren
>>>>>>>> I'm going to be running on the user's desktop and I don't want to >>>>>>>> have the embedded http server running so that I can lock down the system so >>>>>>>> that users can't tamper with the data in any way.
>>>>>>>> Is there any other way I can use to export documents and >>>>>>>> attachments?
>>>>>>>> Also, I have just realised that even if I encrypt the documents in >>>>>>>> the database, the user could download and run Studio against the data. Is >>>>>>>> there any way currently of preventing this, such as whole database >>>>>>>> encryption? If not, will that be available with the encryption features in >>>>>>>> 1.2?
>>>>>>>> Thanks
>>>>>>>> Sean
>>>>>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>>>>>>> You cannot export from an embedded DB without enabling the >>>>>>>>> embedded http server. >>>>>>>>> Smuggler works over HTTP.
> Given that the documents can be encrypted and that (an equivalent to)
> Smuggler can be run without enabling http, then to require a password to
> enable http access to the database from would be all that's needed.
> I presume that this, or something similar, is something that you're going
> to add for the enterprise encryption in 1.2?
> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>> Sean,
>> Let me rephrase that, what do you want? How do you envision it?
>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>>> Sure, that does prevent a competitor from reading our data. But it
>>> doesn't prevent user tampering nor does it allow me to use the database to
>>> track licensing (as it can be tampered with). There's no way currently
>>> around that then?
>>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>>>> Sean,
>>>> Encrypt the data, that should take you pretty far in only allowing
>>>> access from your own software.
>>>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>>>> The end users are electrical engineers as private engineers or
>>>>> companies. The product is licensed to the PC itself and we do eperience a
>>>>> fair amount of end user tampering. Part of the licensing and machine
>>>>> locking is tracked in the database itself, so it['s important that they
>>>>> cannot remove this.
>>>>> The other motivation is to prevent competitors from accessing our
>>>>> data. To be able to upgrade from our data is an attractive selling point
>>>>> and I'm a small guy in a market where there are some very established
>>>>> players who have far more resources that I do. That precise scenario
>>>>> happened to me about 10 years ago now, and it hurt!
>>>>> The encryption key is shipped, yes, but it's obfuscated. Sure, you
>>>>> can never totally prevent access, but to raise the bar to the level that
>>>>> the attacker has to crack commercial obfuscation is good enough for our
>>>>> needs. At least I then have legal recourse if that were a competitor.
>>>>> So, is there any way currently or in the fairly near future to prevent
>>>>> user tampering? It sounds from your responses that there isn't, which
>>>>> would be a shame.
>>>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>>>>> At the end, it is a file on his machine.
>>>>>> Sure, you can encrypt that, but the encryption key also has to be on
>>>>>> the machine at some point, so that is pretty meaningless.
>>>>>> Who is the user? What is the data? How important is it to prevent
>>>>>> tampering? Are you likely to be dealing with devs / hackers or with
>>>>>> standard users?
>>>>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>>>>> Thanks, I'll look for Tobi or Justin's code.
>>>>>>> As for the user accessing the data - so there is no way that I can
>>>>>>> prevent the user from editing or deleting documents whatever lengths I go
>>>>>>> to?
>>>>>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>>>>>>> Sean,
>>>>>>>> If the data is on the user's computer, he got it.
>>>>>>>> Oh, you can make it awkward to get it, but they can do that.
>>>>>>>> There is literally no way to hide that if your are running on his
>>>>>>>> machine.
>>>>>>>> I think that there is some code around (Tobi or Justin wrote it, I
>>>>>>>> believe) that will work like the smuggler for the embedded version.
>>>>>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>>>>>>> Oren
>>>>>>>>> I'm going to be running on the user's desktop and I don't want to
>>>>>>>>> have the embedded http server running so that I can lock down the system so
>>>>>>>>> that users can't tamper with the data in any way.
>>>>>>>>> Is there any other way I can use to export documents and
>>>>>>>>> attachments?
>>>>>>>>> Also, I have just realised that even if I encrypt the documents in
>>>>>>>>> the database, the user could download and run Studio against the data. Is
>>>>>>>>> there any way currently of preventing this, such as whole database
>>>>>>>>> encryption? If not, will that be available with the encryption features in
>>>>>>>>> 1.2?
>>>>>>>>> Thanks
>>>>>>>>> Sean
>>>>>>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>>>>>>>> You cannot export from an embedded DB without enabling the
>>>>>>>>>> embedded http server.
>>>>>>>>>> Smuggler works over HTTP.
On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
> You _can_ require a password for HTTP access. That is what the OAuth > bundle does.
> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>> Given that the documents can be encrypted and that (an equivalent to) >> Smuggler can be run without enabling http, then to require a password to >> enable http access to the database from would be all that's needed.
>> I presume that this, or something similar, is something that you're going >> to add for the enterprise encryption in 1.2?
>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>>> Sean, >>> Let me rephrase that, what do you want? How do you envision it?
>>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>>>> Sure, that does prevent a competitor from reading our data. But it >>>> doesn't prevent user tampering nor does it allow me to use the database to >>>> track licensing (as it can be tampered with). There's no way currently >>>> around that then?
>>>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>>>>> Sean, >>>>> Encrypt the data, that should take you pretty far in only allowing >>>>> access from your own software.
>>>>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>>>>> The end users are electrical engineers as private engineers or >>>>>> companies. The product is licensed to the PC itself and we do eperience a >>>>>> fair amount of end user tampering. Part of the licensing and machine >>>>>> locking is tracked in the database itself, so it['s important that they >>>>>> cannot remove this.
>>>>>> The other motivation is to prevent competitors from accessing our >>>>>> data. To be able to upgrade from our data is an attractive selling point >>>>>> and I'm a small guy in a market where there are some very established >>>>>> players who have far more resources that I do. That precise scenario >>>>>> happened to me about 10 years ago now, and it hurt!
>>>>>> The encryption key is shipped, yes, but it's obfuscated. Sure, you >>>>>> can never totally prevent access, but to raise the bar to the level that >>>>>> the attacker has to crack commercial obfuscation is good enough for our >>>>>> needs. At least I then have legal recourse if that were a competitor.
>>>>>> So, is there any way currently or in the fairly near future to >>>>>> prevent user tampering? It sounds from your responses that there isn't, >>>>>> which would be a shame.
>>>>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>>>>>> At the end, it is a file on his machine. >>>>>>> Sure, you can encrypt that, but the encryption key also has to be on >>>>>>> the machine at some point, so that is pretty meaningless.
>>>>>>> Who is the user? What is the data? How important is it to prevent >>>>>>> tampering? Are you likely to be dealing with devs / hackers or with >>>>>>> standard users?
>>>>>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>>>>>> Thanks, I'll look for Tobi or Justin's code.
>>>>>>>> As for the user accessing the data - so there is no way that I can >>>>>>>> prevent the user from editing or deleting documents whatever lengths I go >>>>>>>> to?
>>>>>>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>>>>>>>> Sean, >>>>>>>>> If the data is on the user's computer, he got it. >>>>>>>>> Oh, you can make it awkward to get it, but they can do that. >>>>>>>>> There is literally no way to hide that if your are running on his >>>>>>>>> machine.
>>>>>>>>> I think that there is some code around (Tobi or Justin wrote it, I >>>>>>>>> believe) that will work like the smuggler for the embedded version.
>>>>>>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>>>>>>>> Oren
>>>>>>>>>> I'm going to be running on the user's desktop and I don't want to >>>>>>>>>> have the embedded http server running so that I can lock down the system so >>>>>>>>>> that users can't tamper with the data in any way.
>>>>>>>>>> Is there any other way I can use to export documents and >>>>>>>>>> attachments?
>>>>>>>>>> Also, I have just realised that even if I encrypt the documents >>>>>>>>>> in the database, the user could download and run Studio against the data. >>>>>>>>>> Is there any way currently of preventing this, such as whole database >>>>>>>>>> encryption? If not, will that be available with the encryption features in >>>>>>>>>> 1.2?
>>>>>>>>>> Thanks
>>>>>>>>>> Sean
>>>>>>>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>>>>>>>>> You cannot export from an embedded DB without enabling the >>>>>>>>>>> embedded http server. >>>>>>>>>>> Smuggler works over HTTP.
Oren, thanks again for your help. It looks like exactly what I needed.
I'm using OAuth as I don't want the domain to control access. This sets up a default user and spits out the password to a file ( EnsureAtLeastOneUserExists startup task). What's the best way to prevent this happening?
On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
> Fantastic, thanks! I'll take a look at that now.
> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
>> You _can_ require a password for HTTP access. That is what the OAuth >> bundle does.
>> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>>> Given that the documents can be encrypted and that (an equivalent to) >>> Smuggler can be run without enabling http, then to require a password to >>> enable http access to the database from would be all that's needed.
>>> I presume that this, or something similar, is something that you're >>> going to add for the enterprise encryption in 1.2?
>>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>>>> Sean, >>>> Let me rephrase that, what do you want? How do you envision it?
>>>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>>>>> Sure, that does prevent a competitor from reading our data. But it >>>>> doesn't prevent user tampering nor does it allow me to use the database to >>>>> track licensing (as it can be tampered with). There's no way currently >>>>> around that then?
>>>>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>>>>>> Sean, >>>>>> Encrypt the data, that should take you pretty far in only allowing >>>>>> access from your own software.
>>>>>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>>>>>> The end users are electrical engineers as private engineers or >>>>>>> companies. The product is licensed to the PC itself and we do eperience a >>>>>>> fair amount of end user tampering. Part of the licensing and machine >>>>>>> locking is tracked in the database itself, so it['s important that they >>>>>>> cannot remove this.
>>>>>>> The other motivation is to prevent competitors from accessing our >>>>>>> data. To be able to upgrade from our data is an attractive selling point >>>>>>> and I'm a small guy in a market where there are some very established >>>>>>> players who have far more resources that I do. That precise scenario >>>>>>> happened to me about 10 years ago now, and it hurt!
>>>>>>> The encryption key is shipped, yes, but it's obfuscated. Sure, you >>>>>>> can never totally prevent access, but to raise the bar to the level that >>>>>>> the attacker has to crack commercial obfuscation is good enough for our >>>>>>> needs. At least I then have legal recourse if that were a competitor.
>>>>>>> So, is there any way currently or in the fairly near future to >>>>>>> prevent user tampering? It sounds from your responses that there isn't, >>>>>>> which would be a shame.
>>>>>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>>>>>>> At the end, it is a file on his machine. >>>>>>>> Sure, you can encrypt that, but the encryption key also has to be >>>>>>>> on the machine at some point, so that is pretty meaningless.
>>>>>>>> Who is the user? What is the data? How important is it to prevent >>>>>>>> tampering? Are you likely to be dealing with devs / hackers or with >>>>>>>> standard users?
>>>>>>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>>>>>>> Thanks, I'll look for Tobi or Justin's code.
>>>>>>>>> As for the user accessing the data - so there is no way that I can >>>>>>>>> prevent the user from editing or deleting documents whatever lengths I go >>>>>>>>> to?
>>>>>>>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>>>>>>>>> Sean, >>>>>>>>>> If the data is on the user's computer, he got it. >>>>>>>>>> Oh, you can make it awkward to get it, but they can do that. >>>>>>>>>> There is literally no way to hide that if your are running on his >>>>>>>>>> machine.
>>>>>>>>>> I think that there is some code around (Tobi or Justin wrote it, >>>>>>>>>> I believe) that will work like the smuggler for the embedded version.
>>>>>>>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>>>>>>>>> Oren
>>>>>>>>>>> I'm going to be running on the user's desktop and I don't want >>>>>>>>>>> to have the embedded http server running so that I can lock down the system >>>>>>>>>>> so that users can't tamper with the data in any way.
>>>>>>>>>>> Is there any other way I can use to export documents and >>>>>>>>>>> attachments?
>>>>>>>>>>> Also, I have just realised that even if I encrypt the documents >>>>>>>>>>> in the database, the user could download and run Studio against the data. >>>>>>>>>>> Is there any way currently of preventing this, such as whole database >>>>>>>>>>> encryption? If not, will that be available with the encryption features in >>>>>>>>>>> 1.2?
>>>>>>>>>>> Thanks
>>>>>>>>>>> Sean
>>>>>>>>>>> On Monday, 30 April 2012 05:04:53 UTC+1, Oren Eini wrote:
>>>>>>>>>>>> You cannot export from an embedded DB without enabling the >>>>>>>>>>>> embedded http server. >>>>>>>>>>>> Smuggler works over HTTP.
On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
> Fantastic, thanks! I'll take a look at that now.
> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
>> You _can_ require a password for HTTP access. That is what the OAuth >> bundle does.
>> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>>> Given that the documents can be encrypted and that (an equivalent to) >>> Smuggler can be run without enabling http, then to require a password to >>> enable http access to the database from would be all that's needed.
>>> I presume that this, or something similar, is something that you're >>> going to add for the enterprise encryption in 1.2?
>>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>>>> Sean, >>>> Let me rephrase that, what do you want? How do you envision it?
>>>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>>>>> Sure, that does prevent a competitor from reading our data. But it >>>>> doesn't prevent user tampering nor does it allow me to use the database to >>>>> track licensing (as it can be tampered with). There's no way currently >>>>> around that then?
>>>>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>>>>>> Sean, >>>>>> Encrypt the data, that should take you pretty far in only allowing >>>>>> access from your own software.
>>>>>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>>>>>> The end users are electrical engineers as private engineers or >>>>>>> companies. The product is licensed to the PC itself and we do eperience a >>>>>>> fair amount of end user tampering. Part of the licensing and machine >>>>>>> locking is tracked in the database itself, so it['s important that they >>>>>>> cannot remove this.
>>>>>>> The other motivation is to prevent competitors from accessing our >>>>>>> data. To be able to upgrade from our data is an attractive selling point >>>>>>> and I'm a small guy in a market where there are some very established >>>>>>> players who have far more resources that I do. That precise scenario >>>>>>> happened to me about 10 years ago now, and it hurt!
>>>>>>> The encryption key is shipped, yes, but it's obfuscated. Sure, you >>>>>>> can never totally prevent access, but to raise the bar to the level that >>>>>>> the attacker has to crack commercial obfuscation is good enough for our >>>>>>> needs. At least I then have legal recourse if that were a competitor.
>>>>>>> So, is there any way currently or in the fairly near future to >>>>>>> prevent user tampering? It sounds from your responses that there isn't, >>>>>>> which would be a shame.
>>>>>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>>>>>>> At the end, it is a file on his machine. >>>>>>>> Sure, you can encrypt that, but the encryption key also has to be >>>>>>>> on the machine at some point, so that is pretty meaningless.
>>>>>>>> Who is the user? What is the data? How important is it to prevent >>>>>>>> tampering? Are you likely to be dealing with devs / hackers or with >>>>>>>> standard users?
>>>>>>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>>>>>>> Thanks, I'll look for Tobi or Justin's code.
>>>>>>>>> As for the user accessing the data - so there is no way that I can >>>>>>>>> prevent the user from editing or deleting documents whatever lengths I go >>>>>>>>> to?
>>>>>>>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>>>>>>>>> Sean, >>>>>>>>>> If the data is on the user's computer, he got it. >>>>>>>>>> Oh, you can make it awkward to get it, but they can do that. >>>>>>>>>> There is literally no way to hide that if your are running on his >>>>>>>>>> machine.
>>>>>>>>>> I think that there is some code around (Tobi or Justin wrote it, >>>>>>>>>> I believe) that will work like the smuggler for the embedded version.
>>>>>>>>>> On Mon, Apr 30, 2012 at 12:31 PM, Sean Kearon wrote:
>>>>>>>>>> Oren
>>>>>>>>>>> I'm going to be running on the user's desktop and I don't want >>>>>>>>>>> to have the embedded http server running so that I can lock down the system >>>>>>>>>>> so that users can't tamper with the data in any way.
>>>>>>>>>>> Is there any other way I can use to export documents and >>>>>>>>>>> attachments?
On Monday, April 30, 2012, Sean Kearon wrote:
> Oren, thanks again for your help. It looks like exactly what I needed.
> I'm using OAuth as I don't want the domain to control access. This sets
> up a default user and spits out the password to a file (
> EnsureAtLeastOneUserExists startup task). What's the best way to prevent
> this happening?
> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
> Fantastic, thanks! I'll take a look at that now.
> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
> You _can_ require a password for HTTP access. That is what the OAuth
> bundle does.
> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
> Given that the documents can be encrypted and that (an equivalent to)
> Smuggler can be run without enabling http, then to require a password to
> enable http access to the database from would be all that's needed.
> I presume that this, or something similar, is something that you're going
> to add for the enterprise encryption in 1.2?
> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
> Sean,
> Let me rephrase that, what do you want? How do you envision it?
> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
> Sure, that does prevent a competitor from reading our data. But it
> doesn't prevent user tampering nor does it allow me to use the database to
> track licensing (as it can be tampered with). There's no way currently
> around that then?
> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
> Sean,
> Encrypt the data, that should take you pretty far in only allowing access
> from your own software.
> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
> The end users are electrical engineers as private engineers or companies.
> The product is licensed to the PC itself and we do eperience a fair amount
> of end user tampering. Part of the licensing and machine locking is
> tracked in the database itself, so it['s important that they cannot remove
> this.
> The other motivation is to prevent competitors from accessing our data.
> To be able to upgrade from our data is an attractive selling point and I'm
> a small guy in a market where there are some very established players who
> have far more resources that I do. That precise scenario happened to me
> about 10 years ago now, and it hurt!
> The encryption key is shipped, yes, but it's obfuscated. Sure, you can
> never totally prevent access, but to raise the bar to the level that the
> attacker has to crack commercial obfuscation is good enough for our needs.
> At least I then have legal recourse if that were a competitor.
> So, is there any way currently or in the fairly near future to prevent
> user tampering? It sounds from your responses that there isn't, which
> would be a shame.
> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
> At the end, it is a file on his machine.
> Sure, you can encrypt that, but the encryption key also has to be on the
> machine at some point, so that is pretty meaningless.
> Who is the user? What is the data? How important is it to prevent
> tampering? Are you likely to be dealing with devs / hackers or with
> standard users?
> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
> Thanks, I'll look for Tobi or Justin's code.
> As for the user accessing the data - so there is no way that I can prevent
> the user from editing or deleting documents whatever lengths I go to?
> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
> Sean,
> If the data is on the user's computer, he got it.
> Oh, you can make it awkward to get it, but they can do that.
> There is literally no way to hide that if your are running on his machine.
> I think that there is some code around (Tobi
> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
> Fantastic, thanks! I'll take a look at that now.
> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
> You _can_ require a password for HTTP access. That is what the OAuth
> bundle does.
> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
> Given that the documents can be encrypted and that (an equivalent to)
> Smuggler can be run without enabling http, then to require a password to
> enable http access to the database from would be all that's needed.
> I presume that this, or something similar, is something that you're going
> to add for the enterprise encryption in 1.2?
> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
> Sean,
> Let me rephrase that, what do you want? How do you envision it?
> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
> Sure, that does prevent a competitor from reading our data. But it
> doesn't prevent user tampering nor does it allow me to use the database to
> track licensing (as it can be tampered with). There's no way currently
> around that then?
> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
> Sean,
> Encrypt the data, that should take you pretty far in only allowing access
> from your own software.
> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
> The end users are electrical engineers as private engineers or companies.
> The product is licensed to the PC itself and we do eperience a fair amount
> of end user tampering. Part of the licensing and machine locking is
> tracked in the database itself, so it['s important that they cannot remove
> this.
> The other motivation is to prevent competitors from accessing our data.
> To be able to upgrade from our data is an attractive selling point and I'm
> a small guy in a market where there are some very established players who
> have far more resources that I do. That precise scenario happened to me
> about 10 years ago now, and it hurt!
> The encryption key is shipped, yes, but it's obfuscated. Sure, you can
> never totally prevent access, but to raise the bar to the level that the
> attacker has to crack commercial obfuscation is good enough for our needs.
> At least I then have legal recourse if that were a competitor.
> So, is there any way currently or in the fairly near future to prevent
> user tampering? It sounds from your responses that there isn't, which
> would be a shame.
> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
> At the end, it is a file on his machine.
> Sure, you can encrypt that, but the encryption key also has to be on the
> machine at some point, so that is pretty meaningless.
> Who is the user? What is the data? How important is it to prevent
> tampering? Are you likely to be dealing with devs / hackers or with
> standard users?
> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
> Thanks, I'll look for Tobi or Justin's code.
> As for the user accessing the data - so there is no way that I can prevent
> the user from editing or deleting documents whatever lengths I go to?
> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
> Sean,
> If the data is on the user's computer, he got it.
> Oh, you can make it awkward to get it, but they can do that.
> There is literally no way to hide that if your are running on his machine.
> I think that there is some code around (Tobi or
> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
> Fantastic, thanks! I'll take a look at that now.
> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
> You _can_ require a password for HTTP access. That is what the OAuth
> bundle does.
> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
> Given that the documents can be encrypted and that (an equivalent to)
> Smuggler can be run without enabling http, then to require a password to
> enable http access to the database from would be all that's needed.
> I presume that this, or something similar, is something that you're going
> to add for the enterprise encryption in 1.2?
> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
> Sean,
> Let me rephrase that, what do you want? How do you envision it?
> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
> Sure, that does prevent a competitor from reading our data. But it
> doesn't prevent user tampering nor does it allow me to use the database to
> track licensing (as it can be tampered with). There's no way currently
> around that then?
> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
> Sean,
> Encrypt the data, that should take you pretty far in only allowing access
> from your own software.
> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
> The end users are electrical engineers as private engineers or companies.
> The product is licensed to the PC itself and we do eperience a fair amount
> of end user tampering. Part of the licensing and machine locking is
> tracked in the database itself, so it['s important that they cannot remove
> this.
> The other motivation is to prevent competitors from accessing our data.
> To be able to upgrade from our data is an attractive selling point and I'm
> a small guy in a market where there are some very established players who
> have far more resources that I do. That precise scenario happened to me
> about 10 years ago now, and it hurt!
> The encryption key is shipped, yes, but it's obfuscated. Sure, you can
> never totally prevent access, but to raise the bar to the level that the
> attacker has to crack commercial obfuscation is good enough for our needs.
> At least I then have legal recourse if that were a competitor.
> So, is there any way currently or in the fairly near future to prevent
> user tampering? It sounds from your responses that there isn't, which
> would be a shame.
On Monday, 30 April 2012 19:20:48 UTC+1, Oren Eini wrote:
> Create a user first > Note that embedded access had no security
> On Monday, April 30, 2012, Sean Kearon wrote:
>> Oren, thanks again for your help. It looks like exactly what I needed.
>> I'm using OAuth as I don't want the domain to control access. This sets >> up a default user and spits out the password to a file ( >> EnsureAtLeastOneUserExists startup task). What's the best way to >> prevent this happening?
>> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
>> Fantastic, thanks! I'll take a look at that now.
>> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
>> You _can_ require a password for HTTP access. That is what the OAuth >> bundle does.
>> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>> Given that the documents can be encrypted and that (an equivalent to) >> Smuggler can be run without enabling http, then to require a password to >> enable http access to the database from would be all that's needed.
>> I presume that this, or something similar, is something that you're going >> to add for the enterprise encryption in 1.2?
>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>> Sean, >> Let me rephrase that, what do you want? How do you envision it?
>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>> Sure, that does prevent a competitor from reading our data. But it >> doesn't prevent user tampering nor does it allow me to use the database to >> track licensing (as it can be tampered with). There's no way currently >> around that then?
>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>> Sean, >> Encrypt the data, that should take you pretty far in only allowing access >> from your own software.
>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>> The end users are electrical engineers as private engineers or companies. >> The product is licensed to the PC itself and we do eperience a fair amount >> of end user tampering. Part of the licensing and machine locking is >> tracked in the database itself, so it['s important that they cannot remove >> this.
>> The other motivation is to prevent competitors from accessing our data. >> To be able to upgrade from our data is an attractive selling point and I'm >> a small guy in a market where there are some very established players who >> have far more resources that I do. That precise scenario happened to me >> about 10 years ago now, and it hurt!
>> The encryption key is shipped, yes, but it's obfuscated. Sure, you can >> never totally prevent access, but to raise the bar to the level that the >> attacker has to crack commercial obfuscation is good enough for our needs. >> At least I then have legal recourse if that were a competitor.
>> So, is there any way currently or in the fairly near future to prevent >> user tampering? It sounds from your responses that there isn't, which >> would be a shame.
>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>> At the end, it is a file on his machine. >> Sure, you can encrypt that, but the encryption key also has to be on the >> machine at some point, so that is pretty meaningless.
>> Who is the user? What is the data? How important is it to prevent >> tampering? Are you likely to be dealing with devs / hackers or with >> standard users?
>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>> Thanks, I'll look for Tobi or Justin's code.
>> As for the user accessing the data - so there is no way that I can >> prevent the user from editing or deleting documents whatever lengths I go >> to?
>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>> Sean, >> If the data is on the user's computer, he got it. >> Oh, you can make it awkward to get it, but they can do that. >> There is literally no way to hide that if your are running on his machine.
>> I think that there is some code around (Tobi
>> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
>> Fantastic, thanks! I'll take a look at that now.
>> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
>> You _can_ require a password for HTTP access. That is what the OAuth >> bundle does.
>> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>> Given that the documents can be encrypted and that (an equivalent to) >> Smuggler can be run without enabling http, then to require a password to >> enable http access to the database from would be all that's needed.
>> I presume that this, or something similar, is something that you're going >> to add for the enterprise encryption in 1.2?
>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>> Sean, >> Let me rephrase that, what do you want? How do you envision it?
>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>> Sure, that does prevent a competitor from reading our data. But it >> doesn't prevent user tampering nor does it allow me to use the database to >> track licensing (as it can be tampered with). There's no way currently >> around that then?
>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>> Sean, >> Encrypt the data, that should take you pretty far in only allowing access >> from your own software.
>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>> The end users are electrical engineers as private engineers or companies. >> The product is licensed to the PC itself and we do eperience a fair amount >> of end user tampering. Part of the licensing and machine locking is >> tracked in the database itself, so it['s important that they cannot remove >> this.
>> The other motivation is to prevent competitors from accessing our data. >> To be able to upgrade from our data is an attractive selling point and I'm >> a small guy in a market where there are some very established players who >> have far more resources that I do. That precise scenario happened to me >> about 10 years ago now, and it hurt!
>> The encryption key is shipped, yes, but it's obfuscated. Sure, you can >> never totally prevent access, but to raise the bar to the level that the >> attacker has to crack commercial obfuscation is good enough for our needs. >> At least I then have legal recourse if that were a competitor.
>> So, is there any way currently or in the fairly near future to prevent >> user tampering? It sounds from your responses that there isn't, which >> would be a shame.
>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>> At the end, it is a file on his machine. >> Sure, you can encrypt that, but the encryption key also has to be on the >> machine at some point, so that is pretty meaningless.
>> Who is the user? What is the data? How important is it to prevent >> tampering? Are you likely to be dealing with devs / hackers or with >> standard users?
>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>> Thanks, I'll look for Tobi or Justin's code.
>> As for the user accessing the data - so there is no way that I can >> prevent the user from editing or deleting documents whatever lengths I go >> to?
>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>> Sean, >> If the data is on the user's computer, he got it. >> Oh, you can make it awkward to get it, but they can do that. >> There is literally no way to hide that if your are running on his machine.
>> I think that there is some code around (Tobi or
>> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
>> Fantastic, thanks! I'll take a look at that now.
>> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
>> You _can_ require a password for HTTP access. That is what the OAuth >> bundle does.
>> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>> Given that the documents can be encrypted and that (an equivalent to) >> Smuggler can be run without enabling http, then to require a password to >> enable http access to the database from would be all that's needed.
>> I presume that this, or something similar, is something that you're going >> to add for the enterprise encryption in 1.2?
>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>> Sean, >> Let me rephrase that, what do you want? How do you envision it?
>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>> Sure, that does prevent a competitor from reading our data. But it >> doesn't prevent user tampering nor does it allow me to use the database to >> track licensing (as it can be tampered with). There's no way currently >> around that then?
>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>> Sean, >> Encrypt the data, that should take you pretty far in only allowing access >> from your own software.
>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>> The end users are electrical engineers as private engineers or companies. >> The product is licensed to the PC itself and we do eperience a fair amount >> of end user tampering. Part of the licensing and machine locking is >> tracked in the database itself, so it['s important that they cannot remove >> this.
>> The other motivation is to prevent competitors from accessing our data. >> To be able to upgrade from our data is an attractive selling point and I'm >> a small guy in a market where there are some very established players who >> have far more resources that I do. That precise scenario happened to me >> about 10 years ago now, and it hurt!
>> The encryption key is shipped, yes, but it's obfuscated. Sure, you can >> never
Honestly, let it create the user, then, using the embedded, just modify the
password.
Or don't add the Oauth bundle, create your own that implements
IAuthenciateClient
On Mon, Apr 30, 2012 at 9:49 PM, Sean Kearon <kearon.s...@googlemail.com>wrote:
> Thanks, happy for embedded to have no security from the application, it's
> just other channels that matter.
> As for creating the user first, I have tried to do that, but it's being
> created from an IStartupTask. Is there a way to get in before that runs?
> On Monday, 30 April 2012 19:20:48 UTC+1, Oren Eini wrote:
>> Create a user first
>> Note that embedded access had no security
>> On Monday, April 30, 2012, Sean Kearon wrote:
>>> Oren, thanks again for your help. It looks like exactly what I needed.
>>> I'm using OAuth as I don't want the domain to control access. This sets
>>> up a default user and spits out the password to a file (
>>> EnsureAtLeastOneUserExists st**artup task). What's the best way to
>>> prevent this happening?
>>> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
>>> Fantastic, thanks! I'll take a look at that now.
>>> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
>>> You _can_ require a password for HTTP access. That is what the OAuth
>>> bundle does.
>>> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>>> Given that the documents can be encrypted and that (an equivalent to)
>>> Smuggler can be run without enabling http, then to require a password to
>>> enable http access to the database from would be all that's needed.
>>> I presume that this, or something similar, is something that you're
>>> going to add for the enterprise encryption in 1.2?
>>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>>> Sean,
>>> Let me rephrase that, what do you want? How do you envision it?
>>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>>> Sure, that does prevent a competitor from reading our data. But it
>>> doesn't prevent user tampering nor does it allow me to use the database to
>>> track licensing (as it can be tampered with). There's no way currently
>>> around that then?
>>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>>> Sean,
>>> Encrypt the data, that should take you pretty far in only allowing
>>> access from your own software.
>>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>>> The end users are electrical engineers as private engineers or
>>> companies. The product is licensed to the PC itself and we do eperience a
>>> fair amount of end user tampering. Part of the licensing and machine
>>> locking is tracked in the database itself, so it['s important that they
>>> cannot remove this.
>>> The other motivation is to prevent competitors from accessing our data.
>>> To be able to upgrade from our data is an attractive selling point and I'm
>>> a small guy in a market where there are some very established players who
>>> have far more resources that I do. That precise scenario happened to me
>>> about 10 years ago now, and it hurt!
>>> The encryption key is shipped, yes, but it's obfuscated. Sure, you can
>>> never totally prevent access, but to raise the bar to the level that the
>>> attacker has to crack commercial obfuscation is good enough for our needs.
>>> At least I then have legal recourse if that were a competitor.
>>> So, is there any way currently or in the fairly near future to prevent
>>> user tampering? It sounds from your responses that there isn't, which
>>> would be a shame.
>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>> At the end, it is a file on his machine.
>>> Sure, you can encrypt that, but the encryption key also has to be on the
>>> machine at some point, so that is pretty meaningless.
>>> Who is the user? What is the data? How important is it to prevent
>>> tampering? Are you likely to be dealing with devs / hackers or with
>>> standard users?
>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>> Thanks, I'll look for Tobi or Justin's code.
>>> As for the user accessing the data - so there is no way that I can
>>> prevent the user from editing or deleting documents whatever lengths I go
>>> to?
>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>> Sean,
>>> If the data is on the user's computer, he got it.
>>> Oh, you can make it awkward to get it, but they can do that.
>>> There is literally no way to hide that if your are running on his
>>> machine.
>>> I think that there is some code around (Tobi
>>> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
>>> Fantastic, thanks! I'll take a look at that now.
>>> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
>>> You _can_ require a password for HTTP access. That is what the OAuth
>>> bundle does.
>>> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>>> Given that the documents can be encrypted and that (an equivalent to)
>>> Smuggler can be run without enabling http, then to require a password to
>>> enable http access to the database from would be all that's needed.
>>> I presume that this, or something similar, is something that you're
>>> going to add for the enterprise encryption in 1.2?
>>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>>> Sean,
>>> Let me rephrase that, what do you want? How do you envision it?
>>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>>> Sure, that does prevent a competitor from reading our data. But it
>>> doesn't prevent user tampering nor does it allow me to use the database to
>>> track licensing (as it can be tampered with). There's no way currently
>>> around that then?
>>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>>> Sean,
>>> Encrypt the data, that should take you pretty far in only allowing
>>> access from your own software.
>>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>>> The end users are electrical engineers as private engineers or
>>> companies. The product is licensed to the PC itself and we do eperience a
>>> fair amount of end user tampering. Part of the licensing and machine
>>> locking is tracked in the database itself, so it['s important that they
>>> cannot remove this.
>>> The other motivation is to prevent competitors from accessing our data.
>>> To be able to upgrade from our data is an attractive selling point and I'm
>>> a small guy in a market where there are some very established players who
>>> have far more resources that I do. That precise scenario happened to me
>>> about 10 years ago now, and it hurt!
>>> The encryption key is shipped, yes, but it's obfuscated. Sure, you can
>>> never totally prevent access, but to raise the bar to the level that the
>>> attacker has to crack commercial obfuscation is good enough for our needs.
>>> At least I then have legal recourse if that were a competitor.
>>> So, is there any way currently or in the fairly near future to prevent
>>> user tampering? It sounds from your responses that there isn't, which
>>> would be a shame.
>>> On Monday, 30 April 2012 10:45:39 UTC+1, Oren Eini wrote:
>>> At the end, it is a file on his machine.
>>> Sure, you can encrypt that, but the encryption key also has to be on the
>>> machine at some point, so that is pretty meaningless.
>>> Who is the user? What is the data? How important is it to prevent
>>> tampering? Are you likely to be dealing with devs / hackers or with
>>> standard users?
>>> On Mon, Apr 30, 2012 at 12:39 PM, Sean Kearon wrote:
>>> Thanks, I'll look for Tobi or Justin's code.
>>> As for the user accessing the data - so there is no way that I can
>>> prevent the user from editing or deleting documents whatever lengths I go
>>> to?
>>> On Monday, 30 April 2012 10:34:19 UTC+1, Oren Eini wrote:
>>> Sean,
>>> If the data is on the user's computer, he got it.
>>> Oh, you can make it awkward to get it, but they can do that.
>>> There is literally no way to hide that if your are running on his
>>> machine.
>>> I think that there is some code around (Tobi or
>>> On Monday, 30 April 2012 15:57:36 UTC+1, Sean Kearon wrote:
>>> Fantastic, thanks! I'll take a look at that now.
>>> On Monday, 30 April 2012 15:48:42 UTC+1, Oren Eini wrote:
>>> You _can_ require a password for HTTP access. That is what the OAuth
>>> bundle does.
>>> On Mon, Apr 30, 2012 at 5:17 PM, Sean Kearon wrote:
>>> Given that the documents can be encrypted and that (an equivalent to)
>>> Smuggler can be run without enabling http, then to require a password to
>>> enable http access to the database from would be all that's needed.
>>> I presume that this, or something similar, is something that you're
>>> going to add for the enterprise encryption in 1.2?
>>> On Monday, 30 April 2012 15:03:19 UTC+1, Oren Eini wrote:
>>> Sean,
>>> Let me rephrase that, what do you want? How do you envision it?
>>> On Mon, Apr 30, 2012 at 4:56 PM, Sean Kearon wrote:
>>> Sure, that does prevent a competitor from reading our data. But it
>>> doesn't prevent user tampering nor does it allow me to use the database to
>>> track licensing (as it can be tampered with). There's no way currently
>>> around that then?
>>> On Monday, 30 April 2012 14:19:02 UTC+1, Oren Eini wrote:
>>> Sean,
>>> Encrypt the data, that should take you pretty far in only allowing
>>> access from your own software.
>>> On Mon, Apr 30, 2012 at 4:08 PM, Sean Kearon wrote:
>>> The end users are electrical engineers as private engineers or
>>> companies. The
The application is a touch application running in "kiosk mode" and has a service screen where it opens an embedded browser with Raven.Studio. To avoid the need to enter a password there (The service screen itself already is password-protected), I temporary set:
Thanks Tobi, that's much cleaner than messing around with the default user from the OAuth bundle. How do you register the FixedPasswordAuthenticateClient? I can't find how to do that.
That's an interesting scenario too. I will be putting Raven onto the desktop, so I want to use AllowLocalAccessWithoutAuthorization = false. Works a treat for me.
Do you then run Smuggler across http, or have you embedded that too? If you've embedded it, could you show how you do that?
> The application is a touch application running in "kiosk mode" and has a > service screen where it opens an embedded browser with Raven.Studio. To > avoid the need to enter a password there (The service screen itself > already is password-protected), I temporary set:
> Thanks Tobi, that's much cleaner than messing around with the default user
> from the OAuth bundle. How do you register the
> FixedPasswordAuthenticateClient? I can't find how to do that.
I use this by default for backups because the app is running on different versions of WinXP / Win7 which makes the Esent backups pretty useless if you want to restore a backup on a different machine.
The above code imports/exports the whole database. But I will soon change this to support incremental exports. The Smuggler from RavenDB/unstable already supports this, but I'll do it in a slightly different way.
Thanks very much, that's been really useful and is much appreciated. I'm pretty sure that's all I need to look at now, so I'm off to buy myself an embedded licence and look forward to shipping on Raven :)
On Tuesday, 1 May 2012 11:57:38 UTC+1, Tobi wrote:
> On 01.05.2012 11:44, Sean Kearon wrote:
> > Thanks Tobi, that's much cleaner than messing around with the default > user > > from the OAuth bundle. How do you register the > > FixedPasswordAuthenticateClient? I can't find how to do that.
> I use this by default for backups because the app is running on different > versions of WinXP / Win7 which makes the Esent backups pretty useless if > you want to restore a backup on a different machine.
> The above code imports/exports the whole database. But I will soon change > this to support incremental exports. The Smuggler from RavenDB/unstable > already supports this, but I'll do it in a slightly different way.
> Tobias
On Tuesday, 1 May 2012 11:57:38 UTC+1, Tobi wrote:
> On 01.05.2012 11:44, Sean Kearon wrote:
> > Thanks Tobi, that's much cleaner than messing around with the default > user > > from the OAuth bundle. How do you register the > > FixedPasswordAuthenticateClient? I can't find how to do that.
> I use this by default for backups because the app is running on different > versions of WinXP / Win7 which makes the Esent backups pretty useless if > you want to restore a backup on a different machine.
> The above code imports/exports the whole database. But I will soon change > this to support incremental exports. The Smuggler from RavenDB/unstable > already supports this, but I'll do it in a slightly different way.
Tobi: using your RavenDB Dumper as a basis, I've added attachment capabilities (I have a lot of images in my app). I've tested this only lightly as yet, and it seems to allow my app to backup and restore very smoothly. I've posted this here and would appreciate any comments you may have: https://gist.github.com/2638423
Oren + team: for my scenario - applying OAuth locally and closing down HTTP access - using Smuggler OOTB isn't really an option as far as I can see. To have a fully embedded Smuggler API similar to what Tobi has skinned up would be really great for us embedded-on-the-desktop guys.
On Tuesday, 1 May 2012 11:57:38 UTC+1, Tobi wrote:
> On 01.05.2012 11:44, Sean Kearon wrote:
> > Thanks Tobi, that's much cleaner than messing around with the default > user > > from the OAuth bundle. How do you register the > > FixedPasswordAuthenticateClient? I can't find how to do that.
> I use this by default for backups because the app is running on different > versions of WinXP / Win7 which makes the Esent backups pretty useless if > you want to restore a backup on a different machine.
> The above code imports/exports the whole database. But I will soon change > this to support incremental exports. The Smuggler from RavenDB/unstable > already supports this, but I'll do it in a slightly different way.
> Tobi: using your RavenDB Dumper as a basis, I've added attachment
> capabilities (I have a lot of images in my app). I've tested this only
> lightly as yet, and it seems to allow my app to backup and restore very
> smoothly. I've posted this here and would appreciate any comments you may
> have: https://gist.github.com/2638423
> Oren + team: for my scenario - applying OAuth locally and closing down
> HTTP access - using Smuggler OOTB isn't really an option as far as I can
> see. To have a fully embedded Smuggler API similar to what Tobi has
> skinned up would be really great for us embedded-on-the-desktop guys.
> On Tuesday, 1 May 2012 11:57:38 UTC+1, Tobi wrote:
>> On 01.05.2012 11:44, Sean Kearon wrote:
>> > Thanks Tobi, that's much cleaner than messing around with the default
>> user
>> > from the OAuth bundle. How do you register the
>> > FixedPasswordAuthenticateClien**t? I can't find how to do that.
>> I use this by default for backups because the app is running on different
>> versions of WinXP / Win7 which makes the Esent backups pretty useless if
>> you want to restore a backup on a different machine.
>> The above code imports/exports the whole database. But I will soon change
>> this to support incremental exports. The Smuggler from RavenDB/unstable
>> already supports this, but I'll do it in a slightly different way.
> Tobi: using your RavenDB Dumper as a basis, I've added attachment
> capabilities
Great!
> (I have a lot of images in my app).
How many?
I'm going to add support for product images soon, but haven't decided yet if it's better to store them as attachments or in the file system.
> Oren + team: for my scenario - applying OAuth locally and closing down
> HTTP access - using Smuggler OOTB isn't really an option as far as I can
> see. To have a fully embedded Smuggler API similar to what Tobi has
> skinned up would be really great for us embedded-on-the-desktop guys.
+1 Having import/export in the client-API would certainly be nice.
Apologies for the delayed response - I stupidly decided to fall down a hole on Monday evening and break my foot and I've just come out of hospital. :(
Tobi - about the images: my main root object has up to 5 images. The root has a child which also has an image and there are typically 50 of these children per root. So, about 60 images per root currently. We are going to add a feature to store more images in the near future, which will add up to about about another 200 images per root. I want to store the images in the database. That just makes it easier to backup and restore and is a lot cleaner to code, imo. I also process the images to reduce their size when importing into the application. The main motivation for this is that we have a data sharing facility and I want to ensure that the size of the exchanged files remains as small as possible. I've also added a reference back to your original Gist from mine too :)
Itamar - I really think that this should be a core feature and not rely on a KB article. You should be able to run Smuggler - or similar - in embedded mode without having to enable HTTP. Using HTTP when Raven is running on the user's desktop throws up issues about user permission levels. Yes, I know there is support for this in Raven, but in my scenario I specifically do not want to enable access through Studio as I want to prevent the user from accessing the data easily. How do I add a feature request for this?
On Tuesday, 8 May 2012 23:00:27 UTC+1, Tobi wrote:
> On 08.05.2012 21:03, Sean Kearon wrote:
> > Tobi: using your RavenDB Dumper as a basis, I've added attachment > > capabilities
> Great!
> > (I have a lot of images in my app).
> How many?
> I'm going to add support for product images soon, but haven't decided yet > if it's better to store them as attachments or in the file system.
> > Oren + team: for my scenario - applying OAuth locally and closing down > > HTTP access - using Smuggler OOTB isn't really an option as far as I can > > see. To have a fully embedded Smuggler API similar to what Tobi has > > skinned up would be really great for us embedded-on-the-desktop guys.
> +1 Having import/export in the client-API would certainly be nice.
