[Featureserver] user level cfg?

[Lehtonen, Mika]

One more.

Sorry for any inconvenience, I meant.

Silly me...



Lehtonen, Mika kirjoitti:
> 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,
>>   
>>     
> _______________________________________________
> Featureserver mailing list
> Featureserver at openlayers.org
> http://featureserver.org/mailman/listinfo/featureserver
>