Mailing-List: contact dev-help@openmeetings.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openmeetings.apache.org
Received-SPF: pass (nike.apache.org: domain of kiv.ivan@gmail.com designates
 209.85.223.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJmbs8g0pY7s=S=xGKRpyX4bZSfJvviMV_nZmrhDbRHCOZxq8Q@mail.gmail.com>
References: 
 <CAPCpKOpONaG8NCpbS7xyokwr7tAcN4FG8XmGvPeuhCuBiff=hA@mail.gmail.com>
 <CAJmbs8hczA3fQwGWVUZ50s6wnRVi-LbS04UpAs2CSuhtS+DfnA@mail.gmail.com>
 <CAGc_3jGX67f+buM_rxZJQ3jyvKDdSORDh4ybYXWme6Knhp24SA@mail.gmail.com>
 <CAPCpKOp2DWtXvov5M_OmCRMEF4s94u3wWDWn6Qt3Bejfk1XNmQ@mail.gmail.com>
 <CAJmbs8g0pY7s=S=xGKRpyX4bZSfJvviMV_nZmrhDbRHCOZxq8Q@mail.gmail.com>
From: =?UTF-8?B?0JrQvtGH0YPRgNCwINCY0LLQsNC9?= <kiv.ivan@gmail.com>
Date: Wed, 13 Mar 2013 19:01:35 +0400
Message-ID: 
 <CAPCpKOpQ19+JMHOKDSp4J7-hGTR-DuF19Qr9Kh92D2Lk6rh1Mg@mail.gmail.com>
Subject: Re: bugfix_513
To: dev <dev@openmeetings.apache.org>
Content-Type: multipart/alternative; boundary=14dae9340f8be148dd04d7cfafef

--14dae9340f8be148dd04d7cfafef
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

 I support the solution on creation only one type of user, and cache. For
the user, we need to add the lifetime account (time period or an unlimited.
Use a one-time authorization can bring some problems when required to
reload the page)

The task turns into something more than a bug fix.

Unfortunately, I have little experience with the OM. That will lead to a
major increase development time.


2013/3/11 Maxim Solodovnik <solomax666@gmail.com>

> Unfortunately I don't have "best" solution in mind and would like to
> discuss possible approaches here.
>
> Historically OM has 2 types of hashes
> 1) securityHash
> 2) invitationHash
>
> security hashes are created by OM plugins (for ex.) and allows users of 3=
rd
> party system to login to OM.
> On securityHash generation Sessiondata object with created in DB with
> userdata stored as XML (in Sessiondata.sessionXml field)
> User object will be created as soon as user will use the securityHash (th=
e
> user created will be marked as external and will be unable to login since
> it has no password)
>
> on invitationHash creation the record is added to the invitation table an=
d
> then get used.
>
> So right now we have 2 types of hashes and 3 types of users:
> 1) OM user
> 2) external OM users
> 3) "invitation" users
>
> I always thought all these things need to be generalized. (I really would
> like have only 1 hash and user)
> pros:
> 1) user invited once can be added to the users contacts and then selected
> from contacts while reinviting
> 2) every participant of conference will be user
>
> To implement this I would propose to even
> 1) add type and TTL to the user
> 2) add special user level
> 3) maybe anything else
>
> I would vote for adding type, TTL and hash to the user and remove
> SessionData and various types of hashes.
>
> Or maybe you have better solution
>
>
>
>
> On Mon, Mar 11, 2013 at 4:03 PM, =EB=CF=DE=D5=D2=C1 =E9=D7=C1=CE <kiv.iva=
n@gmail.com> wrote:
>
> > Thank you for your patience and explanation.
> >
> > As I understand it, I have to create a new user along with creating the
> > invitation. The value for the field externalId will be the id invitatio=
n.
> >
> > When the user login on the invitation, we get the user id by externalTy=
pe
> > and externalId.
> >
> >
> > 2013/3/7 Alexei Fedotov <alexei.fedotov@gmail.com>
> >
> > > Afaiu:
> > >
> > > Allowing others to vote can lead to improper results - someone can vo=
te
> > > several times using hashes
> > > 07.03.2013 18:59 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Maxim Solodovn=
ik" <solomax666@gmail.com
> >
> > > =CE=C1=D0=C9=D3=C1=CC:
> > >
> > > > Hello Ivan,
> > > >
> > > > I believe that the only "being" able to participate in conference i=
n
> OM
> > > > room is "*user".
> > > > This concept is true for links created for "external users" during
> > > > integration with various 3rd party CMS systems.
> > > > So, as I said before: the best short term solution would be to
> disable
> > > > voting for "non-users"
> > > > and the best long term solution would be to disable "non-users" in
> > rooms
> > > in
> > > > favor of users with special external type
> > > > or something like this.
> > > >
> > > > On Thu, Mar 7, 2013 at 3:43 PM, =EB=CF=DE=D5=D2=C1 =E9=D7=C1=CE <ki=
v.ivan@gmail.com>
> > wrote:
> > > >
> > > > > Hello Maxim,
> > > > >
> > > > > As I said,
> > > > > "
> > > > > Creation ExternalUser for invited guests is redundant. It will no=
t
> be
> > > > used
> > > > > anywhere else.
> > > > > In the case of my implementation, we have only one additional fie=
ld
> > by
> > > > > which we can determine whether the user is a permanent or externa=
l.
> > > > > "
> > > > >
> > > > > Any problem can be solved in several ways.
> > > > > Explain to me, the inability to use my solution, please. It is
> > contrary
> > > > to
> > > > > anything?
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > > >
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

--14dae9340f8be148dd04d7cfafef--