I've got an unusual problem with WIF. I have to use WIF 3.5 because of compatibility with .Net 4.0.
Following the advice from Vittorio Bertocci here http://www.cloudidentity.com/blog/2010/05/26/your-fedauth-cookies-on-a-diet-issessionmode-true/ We have set IsSessionMode = true in WSFederationAuthenticationModule_SecurityTokenValidated, and most of the time it is working perfectly - we are getting small FedAuth tokens which are pointers to our token in our memory cache.
However, periodically we are getting chunked FedAuth cookies which contain the full token information.
There is no obvious place in our code where we have an alternative code path.
I can't find any other examples of this particular inconsistency on Stack Overflow, or in any blogs about WIF on the wider internet, so I'm throwing this question out here in case anyone else has seen this problem and resolved it.
Meanwhile we are going to try setting up so that we can debug through the WIF code if we can make the problem occur reliably.
We've found out the problem - IsSessionMode was being set in the wrong place, it should have been on SessionSecurityTokenCreated. It appears that it was being set per-instance rather than on init which meant that in some circumstances it had the default value of true.
Could you be sharing another relying party's cookie? One which is not using session? Try explicitly naming each RP's cookie -each one differently.
Related
I'm trying to Put / Patch grants, but get an Ical exception. What is wrong with this:
BEGIN:VCALENDAR
PRODID:prodid
VERSION:2.0
BEGIN:VEVENT
DTEND;TZID=Europe/Amsterdam;VALUE=DATE:30001231
DTSTAMP:20221028T151844
DTSTART;TZID=Europe/Amsterdam;VALUE=DATE:20220824
SEQUENCE:0
UID:f03cdae7-8475-40b5-8521-c902d736e508
END:VEVENT
END:VCALENDAR
Regards,
The problem with your ICAL is the DTEND value with a year of '3000'.
You are right, this ICAL was accepted before, even though it was not supported. We changed this recently and missed that someone had this specified, for what we apologize, of course.
The ICAL grant with such a long timespan is heavy to calculate on the lock and might lead to unexpected results, like grant not being valid after i.e. 10 years.
The maximum timespan that can be specified via ICAL is 68 years with the current locks available on the market.
When not using a reccurence, but simple DTSTART/DTEND, it is recommended to use validFrom/validBefore combination instead of ICAL, that are simpler to calculate on the lock.
In your case validBefore would be null, meaning "unlimited".
We also recommmend you to update existing grants having 3000 year in ICAL to avoid any issues in the future.
To your question about the documentation of API changes, our current API version is always up to date and documented on developers.tapkey.io. We do not intentionally introduce breaking changes, but in this case it was a mistake. Again, we are very sorry for the inconvenience caused.
There is no specific endpoint to test the ICAL, what you can do is to try to create a test grant i.e. for yourself and remove it afterwards.
Thank you for your feedback, we will also try to improve the error message in this case.
These two links reference the ability, in ColdFusion, to get the name of an uploaded file using form.getPartsArray(). However I can not find ColdFusion documentation on it. I would like to use this but not if it has been deprecated or will be. Does anyone have more information on the origin and fate of this function?
ColdFusion: get the name of a file before uploading
http://www.stillnetstudios.com/get-filename-before-calling-cffile/
ColdFusion: get the name of a file before uploading
Ignoring the main question for a moment, can you elaborate on why you want to use it? Reason for asking is the title of the first question might give you a mistaken impression about what that method actually does. Form.getPartsArray() does not provide access to file information before the file is uploaded. The file is already on the server at that point, so in later versions of CF (with additional functionality) it does not necessarily buy you much over just using cffile action=upload.
Does anyone have more information on the origin and fate of this
function?
However, to answer your other question - it is an undocumented feature last I checked. (It was more useful in earlier versions of CF, which lacked some of the newer features relating to form fields and uploads.)
Internally, most form data can be handled using standard request objects, ie HttpServletRequest. However, those do not support multipart requests, ie file uploads. So a special handler is needed. Macromedia/Adobe chose to use the com.oreilly.servlet library for their internal implementation. That is what you are accessing when using FORM.getPartsArray().
The O'Reilly stuff has been bundled with CF since (at least) CF8, which is a good indicator. However, using any internal feature always comes with the risk the implementation will change and break your application. Also, if you move to another engine, the code may not be supported/compatible. So "You pays your money, you takes your choice".
CF8 / Form Scope
I want to notify a client of a specific error condition using a HTTP status code.
The closest I can come by is "416 Range Not Satisfiable" - although the service has nothing to do with serving byte-ranges from files.
Can I liberally interpret the meaning of "Range Not Satisfiable" or must I respect the technical definition involving byte-ranges of files?
You can liberally interpret that. However, that doesn't make it the correct thing to do.
Errors that aren't specifically handled by the current 4xx set generally use the more generic 400 error along with an added explanation as to why. The general rule is that, if your error is an exact match to the more specific code, use it, otherwise use the less specific code.
Overloading the meaning of the specific codes is likely to lead to mass confusion.
As per RFC7231, section 6.5 (my italics):
The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.
Is there any "gauge page" in Internet or some general procedure of querying some popular pages like Google's, so that it return constant known output?
I want to write a Unit test, which will succeeded if internet is working and data is transferring correctly.
UPDATE
I need namely HTTP to check all stack, including my app's part.
I like www.something.com (note the www). It hasn't changed since I found it, and the output is really small.
I don't think it's official or anything though.
I'm increasingly becoming aware that there must be major differences in the ways that regular expressions will be interpreted by browsers.
As an example, a co-worker had written this regular expression, to validate that a file being uploaded would have a PDF extension:
^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$
This works in Internet Explorer, and in Google Chrome, but does NOT work in Firefox. The test always fails, even for an actual PDF. So I decided that the extra stuff was irrelevant and simplified it to:
^.+\.pdf$
and now it works fine in Firefox, as well as continuing to work in IE and Chrome.
Is this a quirk specific to asp:FileUpload and RegularExpressionValidator controls in ASP.NET, or is it simply due to different browsers supporting regex in different ways? Either way, what are some of the latter that you've encountered?
Regarding the actual question: The original regex requires the value to start with a drive letter or UNC device name. It's quite possible that Firefox simply doesn't include that with the filename. Note also that, if you have any intention of being cross-platform, that regex would fail on any non-Windows system, regardless of browser, as they don't use drive letters or UNC paths. Your simplified regex ("accept anything, so long as it ends with .pdf") is about as good of a filename check as you're going to get.
However, Jonathan's comment to the original question cannot be overemphasized. Never, ever, ever trust the filename as an adequate means of determining its contents. Or the MIME type, for that matter. The client software talking to your web server (which might not even be a browser) can lie to you about anything and you'll never know unless you verify it. In this case, that means feeding the received file into some code that understands the PDF format and having that code tell you whether it's a valid PDF or not. Checking the filename may help to prevent people from trying to submit obviously incorrect files, but it is not a sufficient test of the files that are received.
(I realize that you may know about the need for additional validation, but the next person who has a similar situation and finds your question may not.)
As far as I know firefox doesn't let you have the full path of an upload. Interpretation of regular expressions seems irrelevant in this case. I have yet to see any difference between modern browsers in regular expression execution.
If you're using javascript, not enclosing the regex with slashes causes error in Firefox.
Try doing var regex = /^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$/;
As Dave mentioned, Firefox does not give the path, only the file name. Also as he mentioned, it doesn't account for differences between operating systems. I think the best check you could do would be to check if the file name ends with PDF. Also, this doesn't ensure it's a valid PDF, just that the file name ends with PDF. Depending on your needs, you may want to verify that it's actually a PDF by checking the content.
I have not noticed a difference between browsers in regards to the pattern syntax. However, I have noticed a difference between C# and Javascript as C#'s implementation allows back references and Javascript's implementation does not.
I believe JavaScript REs are defined by the ECMA standard, and I doubt there are many differences between JS interpreters. I haven't found any, in my programs, or seen mentioned in an article.
Your message is actually a bit confusing, since you throw ASP stuff in there. I don't see how you conclude it is the browser's fault when you talk about server-side technology or generated code. Actually, we don't even know if you are talking about JS on the browser, validation of upload field (you can no longer do it, at least in a simple way, with FF3) or on the server side (neither FF nor Opera nor Safari upload the full path of the uploaded file. I am surprised to learn that Chrome does like IE...).