openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Кочура Иван <kiv.i...@gmail.com>
Subject Re: bugfix_513
Date Wed, 13 Mar 2013 15:01:35 GMT
 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 3rd
> 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 (the
> 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 and
> 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, Кочура Иван <kiv.ivan@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 invitation.
> >
> > When the user login on the invitation, we get the user id by externalType
> > and externalId.
> >
> >
> > 2013/3/7 Alexei Fedotov <alexei.fedotov@gmail.com>
> >
> > > Afaiu:
> > >
> > > Allowing others to vote can lead to improper results - someone can vote
> > > several times using hashes
> > > 07.03.2013 18:59 пользователь "Maxim Solodovnik" <solomax666@gmail.com
> >
> > > написал:
> > >
> > > > Hello Ivan,
> > > >
> > > > I believe that the only "being" able to participate in conference in
> 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, Кочура Иван <kiv.ivan@gmail.com>
> > wrote:
> > > >
> > > > > Hello Maxim,
> > > > >
> > > > > As I said,
> > > > > "
> > > > > Creation ExternalUser for invited guests is redundant. It will not
> be
> > > > used
> > > > > anywhere else.
> > > > > In the case of my implementation, we have only one additional field
> > by
> > > > > which we can determine whether the user is a permanent or external.
> > > > > "
> > > > >
> > > > > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message