Adjustments to content block numbers

[Alexander Obuhovich]

Currently we use integer numbers to identify content block on the page like this: <inp2:st_ContentBlock num="5"/>. We don't use content block name, since numeric field can be accessed faster in database.

Recently I came across need to place content block below each field on front-end form. To solve my case I passed "prefix" and "field name" as content block number and applied "crc32" function to that string to retrieve proper number.



--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[asd]

I think that the way how in-portal handles user sessions now is quite
strange. Why should session be removed when user loggs-out?
When session is created (user first opened the page) - it contains data
associated exactly with that SESSION
, where the last "session" word actually means some continuously
repeated action (usage of the site).
Sure, session needs to store information about user status (logged-in,
not logged-in), but it shouldnt depend on that. There can still be need
in session-stored data after user logs out. Session should only be
removed when it is expired.
What do you think guys?

[Dmitry Andrejev]

Hi Nikita,

Thanks for your post and thoughts.

You didn't specify which version you have tested on - 5.0.x or 5.1.x?

A few notes to add:

a. Starting In-Portal 5.0 we have changed things in session handling so we only create session when it's needed to store some user specific information, for example you are not logged in (no session created), but get to the registration page where you see a Captcha Image. Obviously we have to store that Captcha code somewhere and this is when the Session will be created and stored in a Cookie. Similar with the sorting of the lists - if user selects to change the sorting it will be sorted in the session (note that this changed in 5.1.0 again for better results).

b. OnLogout I believe we change "u.current_id" to -2 (which is not session depended), destroy the old session and create a new one (all done in Destroy method of InpSession class).

Would you please provide some real life examples were it failed to work right now? This way we can look at both up and down sides of this.

Thanks.

DA.

[asd]

I came across this issue when i was working on facebook connect
integration. As far as the "connection" it self is made on clients side
(client loggs in to the facebook, receives cookie there and then this
cookie gets passed to our site, telling us that the user is really
logged in to the FB) you always need to refresh page at least twice when
user loggs in or out. First time user goes to the FB page where his
session gets created/cancelled, then hi is redirected back and informing
our site regarding his current FB session status. Because of this there
are things that sometimes could be passed only via session. And what i
have faced - is, when logged in user (something already is stored in the
session at this point) loggs out, i loose everything i had stored in
that session.
I hope this helped understanding what i was speaking about.

This was seen on in-portal 4.3.9 but im going to test it out on newer
versions.

[Dmitry Andrejev]

Thanks the details Nikita.

Alex, let's think through the case of what happens if we simple don't Destroy and Create the session on Logout, but keep using the old one?

DA.

[Alexander Obuhovich]

Don't have any specific opinion about that. We need to look on other websites and how they handle session, when user hits logout.

For example there should be other websites with facebook integration and session handling too. Let's analyze how they solved session problem.

Maybe there is some trick in facebook integration.

[Dmitry Andrejev]

Hi Alex, Nikita,


Okay let work on this together.

Nikita, we would need more of your participation in the process. Let's
start with finding some sites were we can follow the idea how their
are doing Facebook Connect and what happens with the Session on User
Log out there.

Once we have about 2 different sites we can take a closer look and try
pull more ideas from there.

Please update here on the progress.


Thanks.

DA.

[Phil -- wbtc.fr --]

I think we can't hold the whole logic without checking how SSO works with Facebook.

2010/5/14 Dmitry Andrejev <dand...@gmail.com>

[asd]

Hello Dmitry!
There are no problems with Facebook Connect actually, i have solved them
when i was working on it. This story was submitted just as a real life
example case to describe what (in my opinion) is working wrong way in
our sessions mechanism.
Im not sure that you have understood me correctly, so i will try to
explain again (btw i have tested this on In-Portal 5.0.2 and problem is
still present).

How it works now:
1) Log-in to the In-Portal (get authorised with login/password through
front-end);
2) have something stored in the session;
3) log-out;
4) notice that ALL data previously stored in session is lost permanently.

How it should work:
1) Log-in to the In-Portal (get authorised with login/password through
front-end);
2) have something stored in the session;
3) log-out;
4) have ALL the data previously stored in session to stay available,
only individual variable values should change to mark user as being
logged-out (user_id etc).

[Alexander Obuhovich]

I'll wait for other facebook integration research results here.

[Dmitry Andrejev]

Hi Nikita,

Thanks for clarifying on the question - yes, we do understand your point, but before making those changes we really need to look into all aspects of this and would be great to look at some other systems (PHP frameworks) integration with Facebook.

Also, here is what you can do as your own research. Do the SVN checkout of In-Portal 5.1.0 (I think all modules so can see how all works - http://source.in-portal.org/w/in-portal.full/branches/5.1.x) and setup Facebook Connect integration in your local environment. Then try to experiment with adjusting Destroy method of InpSession class so we don't kill the session and create a new one. Then do numerous tests of the whole system/site to see if anything else got affected by this. This will be VERY helpful if do that.

Let us know if there are any issues with the setup or you have any questions.

Thanks.

DA.

[Alexander Obuhovich]

Ping.

[Alexander Obuhovich]

Ping again.

[Phil -- wbtc.fr --]

what do you suggest here?

2010/8/9 Alexander Obuhovich <aik....@gmail.com>

[Dmitry Andrejev]

Hi guys,

Looks like we have came across this topic again which why I am writing here again.

Summary:

We should adjust <inp2:st_ContentBlock num="5"/> tag to accept both "num" and NEW "name" param (will be the same) with ability to specify ANY symbols. In result NAME value will be converted to CRC32 and stored as number in the database. In case if both as specified - NUM will win in order to keep backward compatibility with current (older) In-Portals. We are going to encourage the usage of NAME param by giving a NOTICE that "num" param is deprecated and will removed in a future.

Task:

Add "Name" parameter to st_ContentBlock tag

http://tracker.in-portal.org/view.php?id=921

DA.

--

Best regards,

Dmitry A.

[Dmitry A.]

Alex, please take a look here and feel free to make notes/corrections
if I have missed anything.

Cheers!

DA

On Nov 13, 11:33 am, Dmitry Andrejev <dandre...@gmail.com> wrote:
> Hi guys,
>
> Looks like we have came across this topic again which why I am writing here
> again.
>
> Summary:
>

> We should adjust *<inp2:st_ContentBlock num="5"/> *tag to accept both "num"

> and NEW "name" param (will be the same) with ability to specify ANY symbols.
> In result NAME value will be converted to CRC32 and stored as number in the
> database. In case if both as specified - NUM will win in order to keep
> backward compatibility with current (older) In-Portals. We are going to
> encourage the usage of NAME param by giving a NOTICE that "num" param
> is deprecated and will removed in a future.
>
> Task:
>
> Add "Name" parameter to st_ContentBlock tag
>
> http://tracker.in-portal.org/view.php?id=921
>
> DA.
>

> On Tue, Aug 10, 2010 at 9:19 AM, Phil -- wbtc.fr -- <p...@wbtc.fr> wrote:
>
>
>
>
>
>
>
>
>
> > what do you suggest here?
>

> > 2010/8/9 Alexander Obuhovich <aik.b...@gmail.com>
>
> > Ping again.

>
> >> On Sun, May 23, 2010 at 3:13 PM, Alexander Obuhovich <aik.b...@gmail.com>wrote:
>
> >>> Ping.
>
> >>> On Thu, May 13, 2010 at 10:28 AM, Alexander Obuhovich <
> >>> aik.b...@gmail.com> wrote:
>
> >>>> Currently we use integer numbers to identify content block on the page

> >>>> like this: *<inp2:st_ContentBlock num="5"/>*. We don't use content

[Alexander Obuhovich]

I'm actually against making notice about depricated "num" parameter, since both "name" and "num" parameters have equals value for given tag. User can use one or another, based on situation.

[Dmitry Andrejev]

Okay, it's not a deal breaker for me.

Please make your change to the task then!

DA

[Alexander Obuhovich]

Done. It seems, that you like words like "show stopper" and "deal breaker" :)

[Dmitry Andrejev]

Thanks for updating, Alex!

About your last comment - not quite - in most cases I use NOT before them, which means that there is no need to argue about something that's not important.

DA