[Featureserver] user level cfg?

Lehtonen, Mika mika at digikartta.net
Wed Nov 26 12:59:51 EST 2008


hi,

I'm sensing that this isn't leading anywhere. But really, I'm not 
seeking an ultimate security solution. Just closing the door is better 
than leaving it all open, nevertheless there's no lock.

But you are saying that having cfg per user won't make that true. How 
come other users can see my data if they don't have an access to my cfg? 
Sure they could guess what the name of it might be or crack it easily if 
they were pros'. But they are end users. I want secure my system against 
other end users, not against all the internet users, for God sake! Like 
I said, we won't get paranoid, won't we.

So are you still claiming that other end users can see my data?

I will stop bothering you after this mail. Sorry for any convenience.


- mika -

Christopher Schmidt kirjoitti:
> On Wed, Nov 26, 2008 at 04:33:38PM +0200, Lehtonen, Mika wrote:
>   
>> Hi Christopher,
>>
>> from my point of view, personating a web application is user related, 
>> anyway till some extent, even though any authentication, registration, 
>> session management or what so ever would be used. The idea of attaching 
>> userid into the request was something that just came up. It doesn't 
>> close anything else out. Having a possibility to use your own data in 
>> commonly shared webGIS application without any other end-user seeing it, 
>> shouldn't be so strange idea. For example, without getting paranoid, you 
>> might have something confidential geographic data in your possession, 
>> data which your employer don't want you to share. You wouldn't invite 
>> every man walking in the street to your home, would you?
>>     
>
> Your solution does not help that at all -- security through obscurity
> *isn't*. What you're talking about is still allowing anyone off the
> street to get the data out -- without authentication/authorization,
> nothing is about 'protecting' user data.
>
> Essentially, what you're doing is closing the front door to the house,
> while leaving it unlocked. That's fine for some things -- I'd say that's
> not an unusual practice -- but if I was living in downtown New York, I
> probably wouldn't recommend that practice. The internet is a lot mroe
> crowded than downtown new york. :)
>
> Other end users *can* see it. If that's not a problem, that's fine, but
> it's not specific to a user.
>
>   
>> BTW, I'm not a novice in Python, I'm all new to it. But I'll see what I 
>> can do. Anyway, in order system to be dynamic, you also have to create 
>> those files and manage inserting, deleting and updating of the 
>> datastores. But I guess I can do all that with the Perl script I already 
>> wrote for featureserver.cfg editing.
>>     
>
> Note that I wouldn't use featureserver.cfg files for this at all. I
> would store the configuration data in a database, and I would create a
> Service based on that in Python. The Config file is a convenience -- a
> nice convenience, but not the way I would solve your problem.
>
> But I admit that if you're a Python novice, it's handy. My suggestion
> would be to become less of a Python novice :)
>
> Regards,
>   



More information about the Featureserver mailing list