Macromedia breeze-using the breeze xml web services User Manual
20
Chapter 1: Architecture Overview
About public access permissions
There is a special principal ID which, instead of being a number, has the value
"public-
access"
. This ID sets the default access setting for everyone, whether they are logged in or not.
You can assign any of the following permissions on a SCO for the public-access principal:
denied
Nobody can view, access, or manage the SCO.
view
Anyone can view the SCO, even if not logged in.
view-only
(For presentations only) Anyone can view the presentation, even if not logged in.
However, the permissions set on the presentation’s parent folder do not apply to the presentation.
For example, even if a user has
For example, even if a user has
manage
permission on the parent folder, the user can’t delete a
presentation that has
view-only
permission. (Normal permissions still apply to the presentation;
if the user has
manage
permission on the presentation, the user can delete it.)
view-hidden
(For meetings only) Anyone can attend the meeting, even if not logged in.
However, the permissions set on the meeting’s parent folder do not apply to the meeting.
Never assign
manage
,
presenter
, or
publish
permissions to the public-access principal. Never
assign
view-only
or
view-hidden
permissions to normal principals.
About security and launching content
When you launch a SCO, you must provide authentication. You can do so using any of the
following approaches:
following approaches:
•
When you open the URL of the content, add a query parameter named
session
with a value
equal to the value of the login cookie, as shown in the following example:
http://breeze.example.com/p12345678/?session=breez3238uf298
This approach is a potential security problem because anyone who obtains the specified URL
can act as the logged-in user. If you take this approach, use the cookie for an ordinary user
rather than the cookie for an administrative user.
can act as the logged-in user. If you take this approach, use the cookie for an ordinary user
rather than the cookie for an administrative user.
Also, if a user gives the URL to someone else (for example, by copying it and pasting it into an
e-mail message), they are giving access to their account, which presents a security risk.
e-mail message), they are giving access to their account, which presents a security risk.
•
You can set a BREEZESESSION cookie on the user’s browser, using the value of the login
cookie.
cookie.
However, this approach works only if your application is running on a server with the same
domain name as the Breeze server.
domain name as the Breeze server.
Also, if your application server is a J2EE servlet environment (such as ColdFusion or Java), the
application server might also use a cookie named BREEZESESSION, which results in
potential conflicts between Breeze and the application server.
application server might also use a cookie named BREEZESESSION, which results in
potential conflicts between Breeze and the application server.
•
You can simply open the URL, and require the user to log in again.
This approach is more secure than the others but can result in some inconvenience for users.