<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I was thinking of the SelectFeatures, SelectAggregates and
ExecuteSqlQuery functions.<br>
So "Resource Content" refers to data store content.<br>
<pre class="moz-signature" cols="72">Regards, Kenneth Skovhede, GEOGRAF A/S
</pre>
<br>
<br>
Zac Spitzer skrev:
<blockquote
cite="mid:7a85053e0905200101g5475c349lb82d6a5c560c4122@mail.gmail.com"
type="cite">
<pre wrap="">9. The security level of the user and the render should be seperated, so the
user cannot list resource content, but still render the layer. (relating to 5)
would that require a change to the approach for the viewers n legends ? perhaps
only return a shorten version of ResourceContent with the relevant
info required?
z
On Wed, May 20, 2009 at 5:51 PM, Kenneth Skovhede, GEOGRAF A/S
<a class="moz-txt-link-rfc2396E" href="mailto:ks@geograf.dk"><ks@geograf.dk></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">8. Change the security system to allow overrides properly
Current method is to look at the top folder, then trace down into the
structure.
At any point, a folder can block access, making it impossible to maintain
write access to a single resource,
as all folders in its path must be writeable by the user.
9. The security level of the user and the render should be seperated, so the
user cannot list resource content, but still render the layer.
(relating to 5)
Regards, Kenneth Skovhede, GEOGRAF A/S
Zac Spitzer skrev:
i agree about creating tickets for existing bugs as it also allows some
tracking of comments which the wiki doesn't really help with, trac is
a bit limited there...
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/mapguide/wiki/Future/SecurityEnhancements">http://trac.osgeo.org/mapguide/wiki/Future/SecurityEnhancements</a> ?
shall we bounce the list of ideas round via email first?
1. pluggable external authentication (ie ldap, active directory,
possibly use apache PAM here)
2. case insensitive usernames
3. removing the mandatory anonymous login requirement
4. adding login from anonymous session support to fusion and classic
5. improving MapGuide's "hissy fit" if a user tries to load a map that
contains resources that they don't have permissions to.
6. exposing tile caches via http in a formalised manner, kinda relating to 3
7. switching from http status for errors codes to xml results?
z
On Wed, May 20, 2009 at 5:27 PM, Kenneth Skovhede, GEOGRAF A/S
<a class="moz-txt-link-rfc2396E" href="mailto:ks@geograf.dk"><ks@geograf.dk></a> wrote:
I would not mind writing up a proposal to list issues and workflow for the
login/user-management issues.
The RFC is formal, so I would write it as a wiki page initally, once the
actual issues are decided,
we could create issue tickets for each, and put up an RFC for each of the
breaking changes?
I don't have experience or time enough to actually implement the changes
though.
Regards, Kenneth Skovhede, GEOGRAF A/S
Zac Spitzer skrev:
are there relevant bugs in trac? i had a quick browse but couldn't find any
can we add a security component to trac?
(wish we could assign multiple components to a single issue and
making the field headers like components a hyperlink to all issues
for that component, but I'm just a spoilt old jira junkie)
also related is allowing ldap for user auth and getting rid of the stupid
case sensitive usernames, using XML has quite a few drawbacks
there's a swag of security related items here aren't there? definitely
need an RFC
I reckon autodesk's commercial customers would love this too
and it probably is a show stopper for a lot of larger companies evaluating
MG
z
On Wed, May 20, 2009 at 3:42 PM, Jason Birch <a class="moz-txt-link-rfc2396E" href="mailto:Jason.Birch@nanaimo.ca"><Jason.Birch@nanaimo.ca></a> wrote:
I don't see a lot of use for a login UI without also fixing the MapGuide
security model and improving the way it deals with users accessing maps
which contain resources they don't have permissions to. It's a fairly large
can of worms...
Unfortunately, I don't have any resources (development time, money) to throw
at a problem this size, and I don't feel comfortable writing an RFC without
being able to follow through on it.
Jason
-----Original Message-----
From: Zac Spitzer
Sent: Tuesday, May 19, 2009 10:37 PM
To: MapGuide Users Mail List
Subject: Re: [mapguide-users] Allow access to different layers based on
login
we kinda need a login interface with the viewers,that way if anon
access is allowed
it should be the default, then allowing the users to login if they want/need
to
the whole anonymous login stuff is rather annoying
time for an RFC maybe?
_______________________________________________
mapguide-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-users">http://lists.osgeo.org/mailman/listinfo/mapguide-users</a>
_______________________________________________
mapguide-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-users">http://lists.osgeo.org/mailman/listinfo/mapguide-users</a>
_______________________________________________
mapguide-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-users">http://lists.osgeo.org/mailman/listinfo/mapguide-users</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>