What's the scope of a profile attribute in Siebel? - siebel

In Siebel (7.8 in case it makes any difference), what's the scope of a profile attribute set via TheApplication().SetProfileAttr("name", "value");?
I always have seen them as if they were session variables. However, on second thought, the user profile should depend only on the current user, not on the session. So if somebody accesses the Siebel application from two different computers using the same login, and executes an action which sets a profile attribute... would that attribute be readable from the other computer aswell?
I haven't found anything in the official documentation, and googling about it shows contradictory information. Most of the resources say that they're equivalent to session variables...:
Siebel Unleashed: Siebel server recognises every unique user through session id [...] Profile Attributes are variables that can hold any value during the session of the user
Another blog: Profile attributes are set at the session level
An answer in this thread: getsharedglobal [...] can be viewed as a global attribute set at application level. [...] profile attributes are user and session specific so if the same user logins at 2 place he will be having his own set of profile attributes at each place
...but there are others which imply that actually, attributes are only unique per user, not per session:
Another answer in the same thread: The main difference about [SetProfileAttr and SetSharedGlobal] is that [...] SetSharedGlobal [...] is unique to the user and the user's associated session.
So, which one is it? Are they session variables? Or are they bound only to the user, and shared across all the live sessions from the same user?

I have no code to demonstrate this, but from personal experience, a profile attribute is unique to a user's session. Think of it as a global variable which is alive until the user logs out. If a user logins twice to siebel, those are two different siebel sessions. There is no way for siebel users to transfer profile attributes across logins/sessions. Every task run asynchronously on the server will run as a separate SADMIN login, but they will have their own copies of profile attributes. This means that developers can use/set profile attributes without fear of it affecting any other user logged in.

Related

How to implement a manual security procedure with Django

I'm writing a web application with Django framework. This web application is API based and I'm using Django rest_framework. I have a security issue: On the first page, the user must solve a Recaptcha. After solving the Recaptcha my site gives a session ID to the user and after this, the user must post this session ID in the body of all his/her API calls and every API can be called just once with a specific session ID. In other words, I have a state machine for the APIs being called by the user and in each state, the user can call the APIs which have corresponding outgoing edges from that state.
The purpose of all of the above procedures is preventing the user from crawling my website. (User can't call an API many times with a session ID and he/she should act as a normal user and call every API at most two or three times)
Now my question is that how should I handle this in my Django app? Before this, I just used the ordinary Django session middleware for handling sessions. Now should I handle the authentication process and passing and getting session ID completely in a manual way or is there a way in which I can use that middleware that it can be able to handle my procedure.
You can do this with simply with saving your user's state and in each step update your user's state and consider the next states which user can see.
Use custom permission classes for your APIViews to block such request.
Read more here https://www.django-rest-framework.org/api-guide/permissions/#custom-permissions

Django Multiple concurrent logged-in accounts

In the context of a e-health related service, the end-users (health operators, doctors and physiotherapists) working in the same physical environment and sharing just one client PC to interact with my backend, asked me to provide them with a mechanism to quickly switch among different accounts (security is not a concern most of the time because they are used to work within a LAN but, occasionally, they might work from remote clients, so I must keep an authentication/authorization backend in place). They would log in just once and then, before using the web application, would select their logged-in account from a combobox (sort-of).
The UI model might be the same as in GMail where it's possible to keep multiple logged-in user accounts and switch between them through the account selector in the top right corner.
I'm no django-authentication expert, so I am not able to even tell whether this is possible in the context of a django based app.
Does anyone know of any ready-made app/middleware to get this done? Or maybe point me in the right direction if I have to extend or modify existing code?
Thanks a lot.
I haven't looked for any existing solution for this, so this is how I would go about it from scratch.
You'd need to add storage to the user session to hold multiple users. Currently it looks much like:
{'_auth_user_backend': 'membership.auth_backends.MyCustomAuthenticationBackend',
'_auth_user_hash': 'e2c8ecf1e7ecdbd<snip>',
'_auth_user_id': '3806'}
and I would add an array to the session:
logged_in_users = [{'_auth_user_backend': ... }, {}, {}] # one auth dict per user
Then when you "switch users", edit the session object to move that user's auth details (id, hash and backend) into the top-level ones in the session.
You'll also have to write a custom login function that stores the login into the logged_in_users array, and takes out the bit in the current login function that flushes your session if the key is the same as the session of a different logged in user. Similarly, you'll need to think what happens when you logout.

Tracking anonymous users in Angular app

I am working on SPA AngularJS application which allows users to collaborate on projects and stores history of edits for each user. The requirement is to allow unauthenticated users to manipulate data too. Once the user registers, I need to associate her history of edits with the newly created account. The backend is Django.
What is the best option to track actions of anonymous users?
I can create “anonymous” user at the firs visit, issue JWT, store it in the browser and use to track all the user’s activity. Later on when registering user, just update her profile.
The drawback is that there is a potential to get a lot of orphaned users that need to be periodically cleaned up.
This is similar to https://github.com/danfairs/django-lazysignup, but adapted to work with https://github.com/GetBlimp/django-rest-framework-jwt.
Use JWT or cookie to track user session. Allow using session identifier instead of user key to track user’s activity. When creating real user update all references to the session with user’s pk.
Anything else?
From my experience go for solution 1. The orphan user is often not a problem because from business plan point of view it's user and the more is better.
Also having only a notion of user is really simpler. They are users who haven't fully completed their profile that's all.

Hints for the logic of django app

I'm learning Django and for this reason I'm developing an application described below.
This application allows users (authenticated and anonymous) to send message to other users.
Authenticated users can send message and can track all messages simply as all application that uses this feature. (like Facebook messages, for example)
The problem are anonymous users. I would an anonymous user can send message to other users but he can track his messages only for his session. Users can also reply to a message of an anonymous user but If an anonymous user lost his session lost also his messages.
The problem is, how can I manage anonymous user and their messages for the session only?
Django supports anonymous sessions.
If your app is relatively simple (it sounds like it is), I would do the following:
Create a standard Django user profile model and link that to the users messages but do not use OneToOne to connect to User.
Use database backed sessions (https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-database-backed-sessions)
Create a temporary user profile model for anonymous users and store
their temporary profile id in their session.
Once a day delete all profile objects that do not have a user AND
whose id is not in the sessions table. A simple way (and what I would do) is have a created date/time field on the profile and just delete any profile that was created two weeks or more ago and has a null user field. I'd just crontab a django management command.
The cool thing is that if somebody registers after using the app anonymously for a while you can use their temporary profile as their profile and they keep their messages.

How do I set/get a cookie in django that is available if user is logged in AND logged out

I understand request.sessions dictionary and how to use this.
However, it appears that values set using request.sessions is only valid while the user is logged in.
I need to set a persistent cookie that lasts for a fixed time period and not dependent on whether the user is logged in or not.
What I would like is to store a value for an anonymous visitor to my site, and also retrieve that same value if that user creates an account and logs into the site. The value should be retriEvable if the user logs in or logs out between sessions.
Any code examples on this?
Sessions should work fine for anonymous users. What's happening to make you think it only works for authenticated users?
Aside from that, maybe take a look at deferred registration which may do what you're looking for, http://tartarus.org/james/diary/2009/07/24/implementing-deferred-registration-with-django .
As Rolo says, Sessions work when for anonymous users, but When you use the auth.logout method the session is completely wiped. In your logout view, you could call auth.logout, then add whatever data you wish to persist back into the session.