Is it possible to configure Serilog so that the default log file is appended with _001 and if the file limit is reached, that subsequent files are appended with _002, _003 etc.
This is in the context of a ASP.NET Core application.
Unfortunately it's not possible to express this given how the config API has worked since very early days, and, there's no obvious way you make it possible without making the API messy and/or risking breaking people's configs...
As Nick replied to my suggestion
makes sense - the only drawback is that we would risk breaking existing apps by making it the default, and yet it seems too minor to warrant a new top-level configuration option.
Related
Due to the fact that I am using the OWIN authentication, I had to put the cms on a different website. The cms is at cms.domain.com and in my VS project for domain.com I simply pointed the "piranha" connection string to the right database. So far everything was working perfectly, I only had to change the MediaProvider do deal with the domain name issues for the 2 retrieve methods of IMediaProvider.
Now I'm trying to integrate the menu using the #UI.Menu helper, however it looks like the helpers are not using the database of the Web.Config file (I have no problem to retrieve posts from C#). I only see the Start page listed. To confirm it I have also tried to change the site description from cms.domain.com/manager and to display it with the helper #Site.Description but it still shows default site description so it really looks like there is another database around..
Where does data used by the HTML helpers come from? And How can I fix that?
UPDATE : It seems that it is actually a caching issue, it has nothing to do with the connection string.
Piranha CMS caches a lot of meta-data for performance and to minimize the round-trips to the database. The site information, as well as the sitemap is two of these things as these will most likely be used in every page-rendering.
The default cache implementation uses the IIS cache, which is per application pool. The cache is invalidated when data is modified in the manager interface, but if you for example would run the manager interface in another application pool (site/application) this will make the caching fail, causing the kind of errors you describe.
Not being sure how your application is set up, this is my primary guess. If you are in fact running the client web & the manager in different application pools, and you need to continue doing this you should try one of the following approaches.
Implement a distributed cache provider
Set the system param CACHE_SERVER_EXPIRES to 1
Setting the param to 1 invalidates all server cache after one minute. This is of course not to recommend if you are expecting a lot of traffic to your site as it will more or less disable the caching mechanism.
I hope this helps you.
Best regards
Håkan
All of sudden it's now working. The only thing I remember to have done is delete duplicate entries in the dbo.page table. It's all working now, however it doesn't explain why the Site Description wasn't retrieve properly too. But never mind, I hope this will help someone else. I hope custom authentication will be built-in in the next release of Pirhana CMS !
So, my cohorts and I have been doing some development with Phonegap +jQueryMobile for an application we've been planning to rollout. We switched off doing this natively for iOS and Android, since its mostly html anyway, and phone gap seemed like a great way to do this without having to write a whole bunch of platform specific code (although we're more or less newbs when it comes to this type of development.)
Previously, all the html, javascript, etc, was going to be housed in the app itself. For the most part, this seemed to work for us, and we advanced our design/testing/etc accordingly. However, things have changed in our approach. For each of our customers (once they go through a log-in/authentication) has a 'starting' html file (essentially 'their' index.html) that is specific to said customer. This was different from before where everyone had the same files.
Now I've played around with storing certain scripts on the web server to try and off-set opening the html running on the server, but it's not really that useful when trying to integrate some of the functionality like the camera or some of the other plugins we're trying to use. It's essentially a form-based application, so this is the ONLY file that will change from customer to customer. Also, this will not be something that changes frequently. For the most part, it will be setup for a customer ONCE AND ONLY ONCE, and it truly is unlikely to change.
Is there a way to more or less pull down this html file from a web server to replace the one that is stored internally in the app, and then load that version? Would doing something like that (if its even possible) violate Apple's or Google's App guidelines? Or is what I'm describing not even possible in the framework?
The only other thing I can think of would be to change the stored 'index.html' file to not load any of the form itself, but rather make ajax (or equivalent) calls to do so, but I've been told by our developer working the web design side of things that it would be a huge pain.
Any insight/knowledge would be appreciated.
If you really need to do this (I don't quite understand why), I think your best bet is to go the AJAX route. At least Apple does not look kindly on applications that update themselves without going through the App Store submission process.
You can do the same index.html for all and a script config.js that be the responsible of load/unload resources/html of each user at app start.
All you need to do then is save that config JSON values in localstorage and go.
We are building an app where multiple websites are powered by a single site on IIS
We have a web-based tool where webmaster can edit the "resx" files, like:
/App_GlobalResources/es/Backend.es.resx
However there is two problems with this:
changing these files effects all sites.
It also causes the entire IIS site to restart.
Is there another approach to this?
I think storing the strings in a DB may be a bad idea as it will cause hundreds of SQL lookups per page.
Use a database driven resource provider that supports caching. And you are in luck because someone else already done it
Do you provide an interface to edit the resx files? If so, cache them in the Application scope and expire the cache when they are updated. Then, store them in the database. This way, you'll have both speed and flexibility.
Just because the data is in database, doesn't mean it'll be slow. Cache is the solution. Of course, the first lookup will be slow, but subsequent lookups will be as fast as you can get.
I have a site where users are uploading files with a form and it posts and its great, but one customer insists on using FTP instead. I have determined three options for handling this, and I was wondering if anyone has any insight on which is best (or if there is a different overflow I should be asking this on), or if there is a fourth better option.
Solution 1: Learn Linux. I could probably write a cron job that looks in the directory to which they're uploading every 5 minutes and then post the files it finds into my site.
Solution 2: Create a timer driven service in grails that looks in the directory every 5 minutes. This is what I'm going to start trying.
Solution 3: This would be hard, but I'm sure it would be possible to have grails pretend to be a FTP server allowing the ftp dump to be like a post. I have no idea where to start this solution, so unless there is a plugin this isn't happening.
You can use the Grails Quartz plug-in to schedule a task, if you want to pursue option two in your list.
I would go for option 2 and use the Quartz plugin as suggested (rather than cron). Handling files in Groovy are simple and you have lots of examples such as this from mrhaki.
If you think the processing of files will have more complex requirements you could try out something like Apache Camel with this example from the same mrhaki. Though I believe Spring has its own framework that may be a better fit, you'll have to investigate that yourself if you go down that road.
Grails is a web framework so options 2 and 3 are less than ideal. If having the file that is ftped immediately available in your application option 1 is the quickest and simplest solution of the 3 I think.
Another option is to find an open source FTP server (there are several) and modify it to import the document into your system directly. This will allow your client to use the protocol they prefer (FTP) and still get the file into your application in real time.
Still another option is to provide an FTP like client that will use your grails application as the server. Whether this is suitable or not depends on why the client insists on using FTP which you should determine up front to make sure your solution works for them.
I'm a student of web development (and college), so my apologies if this comes off sounding naive and offensive, I certainly don't mean it that way. My experience has been with PHP and with a smallish project on the horizon (a glorified shift calendar) I hoped to learn one of the higher level frameworks to ease the code burden. So far, I looked at CakePHP Symfony Django and Rails.
With PHP, the URLs mapped very simply to the files, and it "just worked". It was quick for the server, and intuitive. But with all of these frameworks, there is this inclination to "pretty up" the URLs by making them map to different functions and route the parameters to different variables in different files.
"The Rails Way" book that I'm reading admits that this is dog slow and is the cause of most performance pains on largish projects. My question is "why have it in the first place?"? Is there a specific point in the url-maps-to-a-file paradigm (or mod_rewrite to a single file) that necessitates regexes and complicated routing schemes? Am I missing out on something by not using them?
Thanks in advance!
URLs should be easy to remember and say. And the user should know what to expect when she see that URL. Mapping URL directly to file doesn't always allow that.
You might want to use diffrent URLs for the same, or at least similar, information displayed. If your server forces you to use 1 url <-> 1 file mapping, you need to create additional files with all their function being to redirect to other file. Or you use stuff like mod_rewrite which isn't easier then Rails' url mappings.
In one of my applications I use URL that looks like http://www.example.com/username/some additional stuff/. This can be also made with mod_rewrite, but at least for me it's easier to configure urls in django project then in every apache instance I run application at.
just my 2 cents...
Most of it has already been covered, but nobody has mentioned SEO yet. Google puts alot of weight on the URL itself, if that url is widgets.com/browse.php?17, that is not very SEO friendly. If your URL is widgets.com/products/buttons/ that will have a positive impact on your page rank for buttons
Storing application code in the document tree of the web server is a security concern.
a misconfiguration might accidentally reveal source code to visitors
files injected through a security vulnerability are immediately executable by HTTP requests
backup files (created e.g. by text editors) may reveal code or be executable in case of misconfiguration
old files which the administrator has failed to delete can reveal unintended functionality
requests to library files must be explicitly denied
URLs reveal implementation details (which language/framework was used)
Note that all of the above are not a problem as long as other things don't go wrong (and some of these mistakes would be serious even alone). But something always goes wrong, and extra lines of defense are good to have.
Django URLs are also very customizable. With PHP frameworks like Code Igniter (I'm not sure about Rails) your forced into the /class/method/extra/ URL structure. While this may be good for small projects and apps, as soon as you try and make it larger/more dynamic you run into problems and have to rewrite some of the framework code to handle it.
Also, routers are like mod_rewrite, but much more flexible. They are not regular expression-bound, and thus, have more options for different types of routes.
Depends on how big your application is. We've got a fairly large app (50+ models) and it isn't causing us any problems. When it does, we'll worry about it then.