Is there any limitation in Tridion that would stop more than one physical user sharing a single Tridion account for logging in?
Tridion as far as I know wouldn't end the other session or log a user out if both logged on at the same time, for instance.
Our client is getting close to their licence limit and is looking several users sharing a single account. From a business perspective they'll lose the ability to really know who changed what - but there's no workflow in place.
Is this in breach of the Tridion licence to do this?
Cheers
Tridion is a stateless application, so although there is authentication there is no concept of log-in or log-out. You could have problems if different users of the account tried to change the same item at the same time (have seen this in training session where a single account was used).
Yes, it would be a breach of the license conditions - typically this is done on a named-user basis, unless unlimited users were allowed (which would probably mean you wouldn't need to do this anyway).
You're right that it would probably work from the software point of view.
But I think we can guess the answer to your license question. After all, it sounds like they are looking at doing this to avoid paying money to SDL for the actual amount of users that they have.
I'm not a lawyer but that doesn't sound like a good idea...
AFAIK SDL Tridion uses sessions bound to the browser, so it doesn't matter from that point of view how many of those session use the same user account. There is no option of loggin out, or ending a session for that matter either.
So yes multiple users can use the same user account but they pose themselves a risk. If user A checks out an item and starts working with this, user B (using the same SDL Tridion account as user A) can also open that item and will not get it in read-only mode (like you would if you were using a different account). So the versioning and locking of items are now bypassed and rendered useless.
Lastly this is indeed violating the license agreement as specified in the contract (unless there is an unlimited number of users granted in the contract).
Related
Seeking some thoughts here. When someone launches my mobile game for the first time, I would prefer they get into the gameplay first before having to worry about "signing up".
I think this provides for a better user experience as you can instantly jump into gameplay. Firebase supports anonymous accounts and saving progress against anonymous accounts, which can later be converted to an actual account (e.g linking their google or facebook accounts to their anonymous account) while retaining their game progress.
Does anyone have any thoughts on this approach or is it better to force a user to decide at app-launch to make a choice between creating an anonymous account or registering using google / facebook / email / etc?
Cheers
Kevin
This is actually a very similar use case to what it often pitched to web developers using Firebase:
For a shopping app, you'll often let a developer go through the shopping flow and finish checkout. When checkout is complete, you then "promote" their account to a full account so you don't bounce a customer out during the critical flow.
For a game, not only do I love this anonymous account flow (play now, then "upgrade" for any social features you need), but I think you can get a really cool natural flow going on. For example, if you were making tic tac toe, you could use a dynamic link to invite your friends to play against you. This link will usually persist across app installation (iOS and Android, although it's a little flakier on iOS) so the player you invite can jump right into the game you're playing using Anonymous Auth to seamlessly create an account.
There are two considerations you need to make though:
You're still storing user data if you pair Realtime Database with an anonymous account. I am not a lawyer, but if your region has strict privacy regulation you will want to talk to one.
The merging an anonymous account into a "full" account process does have some non-trivial edge cases. What do you do if the player already has a full account (obviously, you have to merge the data. But you'll have to do it by hand as there's no game-agnostic way for Firebase to do it for you)? What do you do if a different user claims the same email address when you promote your account (you'll need to throw one out, and there are rules for resolving which has the stronger claim to the name)?
2 is a little complicated also by the current architecture of the Firebase auth SDK as well. All of the C# objects are pointers to C++ objects under the hood. The "current user" was bound in a way that it references a global singleton on the C++ side representing user data. This has the unfortunate side effect that you can't cache a user data on the C# side in the case of a user entering their credentials incorrectly when "upgrading" an account (usually manifesting itself in having to re-enter a username/password and maybe losing cached data). This bug is actively being tracked (I believe it's a side-effect of this one), but in the near term it just means that you probably want a good way to either re-upload local data (assuming you'll lose access to the DB node once you drop the anonymous account) or you'll want to avoid persisting any user-specific data before migrating a player to a "full" account (probably a consideration I'd have with current privacy regulations anyway).
What are the pros and cons of Azure Active Directory to manage the accounts of a simple website (at most 10 accounts, just for login to control panel), instead of SQL membership provider or the new bogus identity system in my own database. I never tried this service before but I like the fact that I don't need to take care of the database and credentials of my users, it's free and very secure I guess. Someone has tested it in production? any security advise? thanks.
Among the many upsides there's that it is free, highly available, enterprise-grade and basically management-free - all flows for entering and changing passwords and similar are already implemented for you. Also, it can be used for both web sites and web API - so that if tomorrow you want to add a mobile app for the same user population, we've got you covered.
About having tested it in production... yes, there are many many (MANY) apps using AAD in production today.
I guess that one possible downside for such a small use case is that all the defaults are set to a higher security level than you'd probably use in your scenario, translating in a bit more involvement from your users: passwords templates requiring special characters, mandatory password expiration, and so on. Of course to me it's a good thing, but I am biased :-)
Another current limitation is that the user names must be of the form alias#yourADdomain, as of today you cannot use an arbitrary string. That's usually not a big deal, but calling it out in case you have preexisting user names you need to stick to.
HTH
V.
This question is not related to ASP.NET specifically, but more web applications in general.
I am building a web application wherein I am registering a user. As of now I am taking in very basic credentials like First Name, Last Name, etc of the user. In this website I am giving some information for free for any user who has just registered so that the user finds my website authentic and that it is not a fake website. After that, to get more information, the user has to pay.
The information my site provides will get obsolete after sometime. So, when a new user registers, he/she will get the new information that gets updated; but the old users have to pay to get the same new information.
My problem here is once the information gets obsolete the same person can re-register with a different set of credentials and get the new information. I want to avoid this from happening.
So my question here is this: what information should I request from the user, or extract from the user, to check that the same user is not re-registering? Or any other way to make this possible.
I am thinking of getting the IP address of the machine from which the person is registering and use it to check. But the user can use a different machine to re-register.
I am completely lost here and not getting the solution. I even checked on the Internet but could not find an answer.
Please let me know if you need any further information from my side.
You will not find a technical way to prevent users from registering multiple times. They can simply use another device, IP, another email account and different credentials.
What you can do is asking them to send you hard to fake "offline" information, like a credit card number or a photo of the ID. Some users may still be able to register multiple times this way, but probably not indefinitly. You will however lose many possible clients this way who are unwilling to provide such information for a test account, so this is likely not the solution you want.
My advice would be one of the following two:
Limit the information/service you give out to free users, so that even if they register again they will gain something when they pay.
Try to bind them to their account in a way where they would lose something if they threw it away. This may for example be providing user rewards for activity (real or virtual) or increasing their experience based on their history. Take SO for example: If you registered again, you would lose all your reputation. The users will think twice if this is worth the new content.
After reading all of the above, i think a good solution could be to let the user identify himself through facebook or linkedin. Few people will have a second account.
I think you cannot put any users like that because every thing can be duplicate
There are some ways for which the user must have payment mode or identity details like passport or it is windows application you can have finger scanner it will be definitely Unique..
You can do this (with limitations) with the use of cookies. Setting a cookie on the users device will allow you to determine who the visitor is and that they have already registered.
The limitations are that cookies can be deleted or blocked and are only valid for that specific user agent - the user could use a different device or a different browser on the same device. A lot of people don't really know about cookies though and how to delete them.
By tying this technique with a requirement to provide a valid email address you can make it a hassle for somebody to register more than once as they will have to create a new email account and then delete their cookies.
Whether this will stop enough people depends on your site and your requirements - if you're giving money away then this technique is not nearly good enough. If you just want to discourage the practice of multiple accounts it may be enough.
Your only way out is to have SOMETHING the existing user gets as a "gift?" or added value to maintain just one account. If you can identify items of value to your subscribers and offer to "give" it to them provided their account "attains" one or more status, then you'll get some control. Take stackoverflow.com for example, I don't need a second account.
Identifying by facebook or linkedin is a good option, but if you are giving such services. which are very beneficial for the users, so they dont mind on creating multiple accounts on even facebook or linked in.
So what i think is to set some reward type stuff with each user, and increase the services as they get increment in rewards.once they are good in rewards and are capable to use multiple services, this increases the probability that they will not create another account.
I need to prevent all CRM Online users from logging in for a short period time while I perform an upgrade to some of the customizations.
Disabling each user is time consuming and I believe that disabling will require a new "invitation" after the user is re-enabled.
What is the best approach for this?
I would suggest trying to disable the Business Unit. But you cannot do this if you only have one Business Unit defined.
http://rc.crm.dynamics.com/rc/2011/en-us/online/5.0/Help/source_set_BU_EnableDisable.htm
According to the online documentation above, disabling the BU will disable login for all users.
We would have to deduce a suitable methodology for managing this, for instance having a single user in a second “administrative” BU that you would login as that user to manage this process.
Recently i received an interview question.
How to maintain search day to day search history in an asp.net application?
Which one of the below would be the right choice?
1)Cookies 2) Sql Server 3) Session State
I guess the correct option could be Cookies.Please kindly share your thought.
SQL Server is the most reliable way of maintaining whatever. Cookies cannot generally be relied upon, and sessions expire and lose all data.
So the question boils down to: if you need to mainain long-term historical records, go with SQL Server. If you want to show what a particular user has searched for, go for session (or cookies, but they're somewhat size-limited).
All 3 options are acceptable in different scenarios for many different reasons - it's a softener question designed to get you thinking and talking:
(1) Cookies - for a per user / browser session provides a client-side solution (provided the user accepts / does not delete them) and you don't care that this can happen. However, this does tie the user to the browser. Useful for anonymous per-user browsing but not if your intention is to keep or query the history.
(2) SQL - guarantees history is saved server side but you would need a mechanism such as a client login to associate the history with the user and the only solution of the 3 presented that would allow you to perform any sort of historical multi-user analysis / analytics.
(3) Session state - not advisable - but arguably similar to cookies but without the caveat that cookie acceptance is required - however you introduce the timeout issue and again tie the user to the browser and limited lifetime of the information.