Has anyone worked with enabling/disabling tracking consent with sitecore 10.1?
I tried the below but it does not seem to work as consentChoice.IsGiven is always returned as true(even after the revoke code is executed):
: https://doc.sitecore.com/xp/en/developers/101/sitecore-experience-platform/manage-a-contact-s-tracking-consent-choices.html
Also, when I set explicitConsentForTrackingIsRequired to true for my site the tracking code starts giving an error.
Regarding
consentChoice.IsGiven always returning true, my initial suspect is your browser cache, your previous site visit might have already captured or set SC_TRACKING_CONSENT (which is set on call to GiveConsent) , if this cookie exists consentChoice.IsGiven is always read from here.
You may need to test this better with either incognito(if using chrome also ensure no shared incognitos) or ensure to force hard refresh (clear cookies) before testing this.
Tracking error code you are facing when explicitConsentForTrackingIsRequired is set to true, this could be due to multiple issues -> ensure xDB tracker is enabled before enabling the consent setting, or check if you have any code attempt to explicitly Start Tracking or access to Tracker.Current.Contact before User Consent has been given. This may throw random errors and error log would help pin point these if you have better example of errors facing.
In addition to these I had also faced errors using this in conjunction with sitecore forms:
When using forms along with explicitConsentForTrackingIsRequired there is an issue where forms auto starts tracking on interaction with form elements , forms has a missing condition check for User Consent before starting tracking.
Please check the answer here for workaround if it is the case.
We have a very weird issue in our Siebel 7.8 application.
In the Application_Start event we define a bunch of profile attributes, which determine if the logged user will be allowed to perform certain operations or not. The code is something like this:
if (userHasSuperpowers) {
TheApplication().SetProfileAttr("CanFly", "Y");
} else {
// CanFly is not set, and GetProfileAttr("CanFly") returns ''
}
Everything works fine, except for one of these profile attributes. The conditions are not met, so we don't set its value. But when we check it using GetProfileAttr... it returns 'Y' instead of ''.
I've checked the code. A lot. I've put traces everywhere, and I'm 100% sure that when the last line of the Application_Start event executes, the attribute is still empty. However, in the first Applet_Load event after the login (in the HLS Salutation Applet (HLS Home) applet), its value has already changed to 'Y'. Why!!? I've looked everywhere, but I can't find anywhere else where we'd be doing a SetProfileAttr. So far, I've ruled out:
Every browser and server script for all our applets, application, BCs and business services.
All the runtime business services (the ones defined directly in the application instead of the SRF).
The Personalization Profile business component fields.
SmartScripts (not that they would matter in this particular scenario, I just mention them to acknowledge that you can set profile attributes there too).
Workflows: every step invoking the SIS OM PMT Service method Set Profile Attribute.
Siebel magically setting its value. The profile attribute name is custom made, in Spanish, and it contains our project name and a row_id. I really don't think Siebel is using the same name for its own profile attributes :).
But wait, there is more, I left the best part for last: the problem only happens in our development environment!
It's not an SRF issue: if we promote the same SRF to our testing or production environments, it works and returns the expected value.
It's not a data problem: still with the same SRF, I can use my local thick client, connecting to our development database with the same login and password, and it works fine too.
It's not a concurrency problem: we are testing with only one user logged in. And even if we had more, they wouldn't share sessions. And even if they did, the value wouldn't be always 'Y'.
It's not a temporary glitch, or something due to a wrong incremental compilation or a corrupted SRF: we have been experiencing this for at least 6 months (obviously, in that time frame, we've had dozens of different SRF files... all of them having the same problem, but only in development, and only if you use the server and not the dedicated client... seriously...).
Where else could I search the profile attribute being set? I've read that they can be persisted to the DB, but in order to do so, you have to define them as a field in a BC based on an S_PARTY extension table, right?
Is there any way to trace profile attribute changes somehow? Maybe rising some loglevel?
How can I find out at least what's being executed after the Application_Start, before loading the first applet?
Any other ideas? I tried checking the SQL spool file too, but didn't find anything suspicious there either (i.e., any of the queries we use to check the conditions, being run twice with different parameters).
Update: following Ranjith R's suggestions, I've also checked:
Other vanilla business services which could be also invoked from a workflow to set a profile attr: User Registration > SetProfileAttr, SessionAccessService > SetProfileAttr and ISS Promotion Agreement Manager > SetProfileAttributes.
Runtime events setting profile attributes directly or using a business service (we don't have any runtime events apart from the vanilla ones).
Business services being called from DVMs (we only have vanilla data validation rules, and none of them apply to our buscomps).
Still no luck...
Ok... finally we found what's happening:
We access the URL to our server and get to the login page. This triggers a first Application_Start event, for the SADMIN user.
We set the profile attributes in that session. SADMIN is the Siebel administrator user, so yes, he hasSuperpowers and therefore we do TheApplication().SetProfileAttr("CanFly", "Y");.
The Application_Start event finishes.
We enter our username and password in the login screen to access into Siebel. This triggers a second Application_Start event, this time for our user. This is the one I was monitoring with the trace files.
We set the profile attributes again in the new session. Our user doesn't hasSuperpowers, so we don't set any value for the CanFly attribute.
The Application_Start event finishes, and CanFly is still empty.
Siebel merges both sessions into one before loading the first screen!! Or at least, it transfers over the profile attributes we had set for SADMIN.
I'm sure it happens that way, for two reasons. First, we changed the profile attribute name to include the username too. And second, instead of storing just an "Y", we are storing now the current date:
var time = (new Date()).getTime();
TheApplication().SetProfileAttr("CanFly_" + TheApplication().LoginName(), time);
We end up having CanFly_SADMIN, but no CanFly_USER, and the time value stored is the same we see in the log file for step 2... which is smaller than any of the values for the *_USER attributes.
So that's what happening. I still don't know why Siebel behaves this way, but that would be matter for another question. According to the Siebel bookshelf:
The Start event is called when the client starts and again when the user interface is first displayed.
...but it doesn't say anythign about it being called from two different sessions, different users too, and then merging them together. It must be something misconfigured in our dev environment, considering it doesn't happen in the other ones.
Does Siebel 7.8 have runtime Events? I can't recall. Runtime events have an action set for setevent, which can set/clear profile attributes.
There are still other vanilla business services which can set profile attributes, try searching in tools flat under business service methods for *rofile*tt*.
The SIS OM service can also be invoked from DVMs for from RunTime events directly, so thats also a possibility.
There is no logging system to see values of Profile Attributes changing, testing is the only way out.
I have installed django_two_factor_auth successfully: token logins, backup tokens and SMS via Twilio all seem to work fine. My users will not tolerate having to enter their token for every login, though.
My needs are similar to those discussed in the following:
https://github.com/Bouke/django-two-factor-auth/issues/56
I wish to offer the user an option to defer OTP verification for 30 days after a successful verification.
To this end, I installed django_agent_trust. I patched AuthenticationTokenForm to add a BooleanField if django_agent_trust is installed:
(two_factor/forms.py, in AuthenticationTokenForm)
try:
from django_agent_trust import trust_agent
trust_this_agent = forms.BooleanField(label=_("Trust this browser for 30 days"),
required=False)
except:
pass
and I have been able to unconditionally set and reset the is_trusted flag by using django_agent_trust's django_agent_trust.trust_agent API.
The problem is figuring out where to capture the user's selected value of the BooleanField. I'm lost somewhere in the form wizard.
I would accept an answer questioning the wisdom of my overall approach if I think your argument makes sense. Is there something I'm missing here?
in the beginning
django_agent_trust seemed like a good shortcut for this use case. It already had secure cookie support, a feature of Django I'd never used before, plus all the convenience methods I thought I'd need.
I was able to get it working with a little extra work.
problem
The problem I ran into was that django_agent_trust validates the signed cookie only after the user is authenticated -- with an authenticated user from the request object. Since I was trying to minimize changes to django_two_factor_auth, I needed to decide whether or not to show the OTP form before authentication occurs.
solution
All the tools I needed were in django_agent_trust. I pulled the methods I needed out of its middleware and into a new utils.py, adding a 'user' argument to load_agent(). Then I was able to check the cookie against the validated-but-not-yet-logged-in user object from django_two_factor_auth's LoginView class.
Now django_two_factor_auth's LoginView can test for agent trust in has_token_step and has_backup_step, and everything works more or less as the author predicted 11 months ago...sigh.
I think adding this trust element might make sense as an enhancement to django_two_factor_auth. Juggling hacks to all these components seems like the wrong way to do it.
later
I took a cue from the django_otp project and added agent_trust as a "plugin" to two_factor. It seems usable and maybe a little easier to digest in this form. This worked for me, but I suspect there's a much better way to do it. Patches welcome.
I'm using devise for an english/french application and have been translating the different views. On devise/passwords/new.html.erb I have a message that appears when a "wrong" email address is entered and the "Send me reset password instructions" button is pressed.
I get the following message if there is an # missing:
A picture of the message
There a different message if there is a # with nothing following, or a # with nothing before.
This message or even type of message doesn't seem to appear elsewhere, which is odd. It doesn't seem to be defined in the following files:
en.yml: github.com/plataformatec/devise/blob/master/config/locales/en.yml
devise_helper.rb: github.com/plataformatec/devise/blob/master/app/helpers/devise_helper.rb
validatable.rb: github.com/plataformatec/devise/blob/master/lib/devise/models/validatable.rb
I think the backend of the message is linked to the regex validating emails and I have no idea where the frontend comes from (keep in mind I'm a bit new to all this). If I can't translate the message, I'd like at least to be able to desactivate this message.
I have done a bit more research and the error message you are receiving seems to be triggered by the browser (you are probably using Chrome). In other words, Devise has nothing to do with it.
The email_field helper probably causes client-side validation from the browser. One option would be to use classic field helpers, such as text_field, or you can add novalidate to prevent client-side validation from the browser. In the last case you should add some own validation if you want some restrictions.
Personally I like simple_form a lot, this is how this problem is countered in simple_form: https://github.com/plataformatec/simple_form/wiki/HTML5-Attributes
Or for a html example: http://www.w3.org/TR/html5/forms.html#concept-fs-novalidate
I am using Django Postman for the intercommunication between two user of my django website .
But when i am sending a message to another user .It is not delivered to the recepient .
I shows me as sent message .In http://127.0.0.1:8000/messages/sent
Here is settings.py setting
############################# Django postman
POSTMAN_AUTO_MODERATE_AS = True
POSTMAN_SHOW_USER_AS = True
POSTMAN_NOTIFIER_APP = True
###################################
And once the messages is sent it is storing properly in the Dtabase but it is not appearing to the recepient inbox.
Please tell me what might I am doing wrong here .
I encountered seemingly identical problem, in my case cause was default moderation.
To better diagnose if this is the case, you can:
check your 'invisible' messages in database, for example using phpmyadmin. If there's 'p' as m moderation_status or anything suspicious under moderation_... columns, this track is probably good;
dig into code: locate postman/models.py and experiment with class MessageManager, method inbox (since other message directories are fine, this one is suspicious). Any of filters there might be cause of your problem - for me it was obviously 'moderation_status'. Even if your case is different, this is good starting point for further debugging.
Use case: let's assume moderation issues
I see that you have
POSTMAN_AUTO_MODERATE_AS = True
set, but perhaps you have left moderation function somewhere, or something gets overwritten in your configuration? Postman's Quick Start Guide indicates that both are necessary:
To disable the moderation feature (no control, no filter):
Set this option to True
Do not provide any auto-moderation functions
I'd suggest removing all other postman specific options from your settings.py, leaving only POSTMAN_AUTO_MODERATE_AS = True and check if there are any utility functions that could potentially interfere with Message objects.
For further reference, more information about moderation is here: https://bitbucket.org/psam/django-postman/wiki/Moderation