[Featureserver] user level cfg?
mika at digikartta.net
Wed Nov 26 14:30:04 EST 2008
Sorry for any inconvenience, I meant.
Lehtonen, Mika kirjoitti:
> 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 :)
> Featureserver mailing list
> Featureserver at openlayers.org
More information about the Featureserver