on production, I set cookieless attribute of sesstionState to AutoDetect, I can see AspxAutoDetectCookieSupport value 1 in developer console of my Edge Browser.
On UAT, I set it to AutoDetect, but never see AspxAutoDetectCookieSupport in developer console.
Is there any other place I need to set it to be able to see it in developer console?
Why does not make any effect ?
Related
Reaching out to anyone who may be able to help.
I have a set of printers (Zebra label printers) that keep on changing printing preferences even though they are saved and set on the server they are installed on.
These preferences are set in Printing Preferences as well as Printing Defaults via Printer Properties.
I can remove the printer and reinstall it via the driver, set those settings again to find them, later on, to be different.
The settings I want to retain are 4X6 in the above picture but they change themselves to USER in the above picture - also not sure where this USER setting is coming from.
Thanks!
I've integrated (but not enforced) App Check within an iOS app of mine, and have a number of requests that are apparently invalid - that is, the requests have an invalid App Check token. I am using Apple's App Attest as the Attestation Provider.
The two example reasons given for this occurring are
"inauthentic client attempting to impersonate your app"
"from emulated environments"
I don't think 1 is happening, because I have a tiny user base (< 10 active users). I also don't think 2 is happening. I very rarely use emulated environments; I prefer building and testing on a physical device.
From troubleshooting on my own, it seems like the issue has to do with me using a debug build on my physical device vs a release build. I followed the instructions here: https://firebase.google.com/docs/app-check/ios/debug-provider, and the errors have apparently dropped to zero for the last 24 hours.
I have two questions:
Is this conclusion correct? That is, is it possible that me using a debug build is what was causing all those unverified requests? The two examples given don't mention anything about a physical device, so I'm not sure if this conclusion is right.
If the answer to 1 is yes, what is the correct workflow setup I should be using? It seems like the debug tokens have the same TTL as the normal App Check tokens (i.e. 1 hour), and manually uploading a token every 1 hour while developing doesn't seem scalable. Is it possible to have the debug tokens have a longer TTL? Or is it possible to upload these tokens through code vs having to manually add via the firebase console?
Firebaser here!
A debug build of your App should fail App Check, part of the verification is that a legitimate device is running a production build of your app. In that regard it is intended and expected.
Using Debug Tokens is the correct approach, the debug token itself will never expire but will be exchanged for an App Check token which will expire in 1 hour or whatever you have your TTL set as by the App Check SDK.
I have problem, in not about coding, but i can't watch a lot of tutorial... I have an youtube account, in my phone anything work, but in my mac not.
I tried to change browser , i tried also to change network, wi-fi , lan, and also broadcasting with my phone but always the same result
I checked in setting and if i check from the icon i have that
but if i check from youtube menu
i have this:
So i read the documentation but i don't find the solution....
How is possible disable the restricted mode ???
if i try to disable from the setting menu( second 4 pic) i have this
But i'm the admin of my pc.... there is only one account ...
help!
I'd like to play back credit card numbers for verification purposes; however, when you do this it exposes the redacted CC in the Request Inspector logs. Of course, I can turn these logs off, but Infosec wants more assurances that Request Inspector remains off and that we have steps in place in case it gets turned back on while live calls are arriving or is turned on and forgotten about.
Aside from seeking to have Twilio set it in a permanent state, I've proposed trying to code a status check that would account for either scenario.
That said though, is the Boolean/Toggle for Request Inspector available to be read from the API?
Example lazy code:
IF(Request inspector = 1) say "Please confirm that you wish to pay xx amount"
else if(request inspector = 0) say "Please confirm that you wish to pay x amount using your credit card 400000000000000"
Basically:
If inspector is on, don't read the CC.
If it's off, you can read CC
Twilio developer evangelist here.
In reality, you should enable PCI mode in your voice settings which is permanent.
As far as I know, you can't read or change the status of the request inspector via the API.
What I might suggest is that for testing you create a separate project within the Twilio console which is responsible for all its own resources. When you run in a test mode you can then use the credentials for this project and log or repeat actions and confirmations as you require. Then, when you run in production mode, you use your production account credentials which are in PCI mode.
I have been given a webtrends DCSID number that is liked with my clients webtrends account.
However I have not been given access to the clients account, so I have no way of verifying if the reporting is working.
Is there a way to verify if it is working, e.g. setting up a trial account to test on?
The target is an iPhone app
You can also download an HTTP monitoring tool that will show you everything that is sent to Webtrends when the tag fires. It won't show you what the reports will look like, but testing the tag should really be the first step in any tagging implementation. If the tagging doesn't work as expected, the reports won't work either. :)
Standalone tools: Fiddler (free) or HttpWatch (basic or paid). Firefox Add-on: HTTPfox (free).
To test how the tag fires from an iPhone, you will need to either use a User Agent switcher/spoofer in your desktop browser, or use an actual iPhone and monitor the traffic using Fiddler—here are instructions. Once you install one of these, look for the hits to http(s)://statse.webtrendslive.com/[the client's DCSID]/dcs.gif?etcetera
You can go to https://tagbuilder.webtrends.com and generate the needed files for tracking, e.g. an empty html page and the javascript. If possible, upload both to a test webspace and access the page. Type into the addressbar
javascript:dcsDebug();
and a small popup will appear. You will now see all informations collected by the javascript and what would be send to the SDC server.
If needed, ask your customer to send you the logfiles of the SDC and compare the logs with your activity.